Hacker News Reader

HNHacker News

Top New Best Ask Show Jobs

Comment by londons_explore | Hacker News Reader

Full thread

londons_explore·

The solution will be "do not share the micro-op cache between different address spaces".

Which for old hardware will translate to "flush the micro op cache every time the address space changes".

I would guess that can be done with a microcode update and that the performance hit wont be too massive.

View on HN

The micro-op cache is very small, on the order of ~1.5K uops AFAIK. It can also be repopulated quite fast. So yes, the performance hit should be quite small. You should presumably also be able to reduce the performance hit if you reduce the frequency of context switches, which should get easier the more cores you have, if I'm not mistaken. That is, the OS can have its own dedicated core, and some programs can be more or less pinned to other cores where they are rarely interrupted.

> You should presumably also be able to reduce the performance hit if you reduce the frequency of context switches, which should get easier the more cores you have, if I'm not mistaken.

Context switches don't happen that often due to preemption unless your CPU is oversubscribed. Most context switches are due to syscalls, especially the ones used to wait for contended locks. Reducing those takes a lot more optimization work.

Given the hockey stick number of cores coming at us, I see pinning and better temporal avoidance being solutions. High security code will be pinned to its own core, running in its own memory area.

So much more scheduler work to do.

Reply on news.ycombinator.com