Hacker News Reader

Comment by praseodym | Hacker News Reader

Google writes that ‘Google Compute Engine employs host isolation features which ensure that an individual core is never concurrently shared between distinct virtual machines’.

However, GCE does offer shared core machine types (f1-micro and g1-small) with 0.2 and 0.5 vCPUs respectively. This seems to contradict their statement (unless the cores are not shared after all, but that doesn’t make sense from an economical standpoint).

Also, they offer machines with one vCPU, but since a vCPU is only a single hyper-thread and not a full core, this still allows for the core to be shared over multiple VMs. If this means that Google will stop using hyperthreading and instead give everyone a full CPU core per vCPU, that will likely give noticeable performance benefits (but cost more for them).

View on HN

I think the key word is 'concurrently'. My guess is that micro and small instances indeed share CPUs, just never 'at the same time' and L1 is flushed before transition from one VM to another.

I work for Google Cloud, but not related to security or OS development, so am not aware how it is actually being done.

seems slow. Having to flush on every swap, I mean. I wonder if there wont be a move away from offering these kinds of offers: if offering 0.2 of a core means putting in 0.3 effort, that's a 20-30% drop in how many you can run per core.

512 entries, 12 cycles to refill each entry from L2, at 3GHz that's only 2 microseconds worst case to refill the L1 cache. And that's if you keep the same task in it. If you're switching tasks most of it is going to get evicted anyway.

GCE uses KVM, which defaults to the linux scheduler with time slices from 0.75ms to 6ms, so the extra impact should be negligible. It's possible they tuned it weirdly, but I can't think of any reason to do so.

Flushes that occur from hypervisor calls could possibly have an impact, but those will happen whether you share a CPU or not.

> and L1 is flushed before transition from one VM to another.

Is this true?

it's what the Google blog post was indicating

I believe that this is likely true as they seemed to implement this for the TLbleed flaw.

The key word is "Concurrently".

They can give both hyperthreads to one machine for 50ms then both hyperthreads to another machine for 50ms.

For VMs with less than 2 vCPUs I suspect they give them two virtual threads and just schedule them for half the time they would otherwise.

Reply on news.ycombinator.com