New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
You are misunderstanding what I mean.
You could have the most dedicated core possible. Performance per core will always degrade as overall load increases. That's why a CPU has a max boost clock and an all-core boost clock.
Even though nobody ever touches your CPU core due to CPU pinning you could suffer a 40% performance loss just because everyone utilize their own core to the full extent.
Dedicated cores does not equal guaranteed performance.
Dedicated cores equals guaranteed usage.
If you need guaranteed performance there is only one way and that is a dedicated server.
I have VDS systems that only have 75% of the CPU cores assigned but still have higher CPU usage than standard VPS packages with 3-4 clients sharing CPU cores simply due to clients that need the highest end CPU with dedicated resources also are the people that need to use the cores extensively.
Sure, that's true, and you'll still have a shared L3 cache with many other nodes (although there is one EPYC that has 32 MiB unshared L3 per core), but you'll still have a minimum guaranteed performance.
A lot of EPYCs and Xeons have their max single core boost very close to their max multi-core boost, so there's not that much a neighbor can do to interfere with your core on a true VDS. Assuming they aren't intentionally trying to cause L3 cache pressure, the most they could do is make the processor reach its thermal limits so you only get the all-core boost instead of single-core boost speed. For a Ryzen that might be a 2 GHz difference, but for EPYC it could be just 100 MHz.
That is interesting concept. Can you make the PoC?
For putting pressure on the L3? Or just making the processor reach its thermal limits?
Both will be nice. I guess the latter's goal is to reach thermal throttling
75% of cores? or threads?
What CPU model?
Putting pressure on the L3 requires populating it with dirty pages and trying to slow down their flush to memory. Create a working set of random data (at least 2x the L3 size) and go over writing to it in a loop with a pseudorandom access pattern with a 64-byte stride. You might be able to do better if you subsequently do a few access in a row to a cache line after writing to it? I think modern caches assign priorities for each cache line and accesses might increase priority and cause evictions.
If you have a lot of cores, you can have a few other cores use
clwbto force writeback to memory by writing to a single cache line over and over to saturate the memory bus. That would keep the dirty L3 lines resident for longer so that they can't be evicted by the "victim" cores. The end-result will be that any working set larger than their L2 will suffer significant cache misses and serving those misses will be slower. Inclusive caches like Intel's will suffer even more.Reaching thermal throttling is easier. Just run something AVX2/AVX512-heavy like a GB benchmark or stress test. That will bring you up to the single-core max boost for a short time, which means anyone else nearby, even if they also have their own pinned cores, can't boost as high anymore. On a Ryzen, this would be particularly effective because you could essentially limit a neighbor's max clock to (say) 3.8 GHz instead of 5.5 GHz. On a server processor with many cores, the limit wouldn't nearly be as severe because the hardware design is focused on best sustained all-core performance rather than temporary single-core performance. So there's not much you can do to your neighbors in that respect.
Okay, so we assumed the microcode will prematurely evict the other guest vm's L3 cache because of the workload characteristic. And this may cause bound on the performance, as the core are starved of the next instruction/data which is stored on RAM
It'll definitely cause evictions because the L3 is shared (assuming you're on the same chiplet, generally). And by having a lot of your L3 contain dirty pages, they can't be evicted until they are successfully flushed to memory.
It won't involve any microcode though, since it's a fast-path that won't touch the microcode sequencer.
Most performance impact won't be pulling in instructions (since those will generally fit comfortably within the L2), but trying to read from or write to the RAM in general. Even if the "victim" can dispatch a memory access instruction, the number of cycles until it retires is going to depend on whether it's a cache hit or a cache miss.
Sorry, this didn't make sense. I was thinking about how you're measuring CPU usage (cores vs threads), not the VM allocation
This doesn't sound bad. Is it still accurate?
@forest, I was able to raise haswell-era node latency. With
bwandread-after-write, butclwbdoesn't exist. The cache latency seems minimal on cascade-lake node, but RAM latency spikes. Do you want to take a look?If you don't have
clwb, you can do something similar withclflush/clflushopt. Those flush a single cache line, so 64 bytes at a time. And cache latency will always be low, but it'll be under pressure. Try doing some data compression and usingperfto measure the cache miss rate. It should go up very high when you're thrashing the cache in another process.Require changed: a single core gb6 at least 2000 is ok