5 ms·
Reading around, Zircon syscalls are non-blocking at the scheduler level. Each syscall still requires a full context switch into kernel mode, though. They can p
by chc4 7y ago
Reading around, Zircon syscalls are non-blocking at the scheduler level. Each syscall still requires a full context switch into kernel mode, though.
They can probably do some smart stuff with having each syscall just add stuff to a work queue so userspace can resume as quickly as possible, but it's still fundamentally more context switches than e.g. Linux would have, which if side-channel attacks keep coming out might be a problem for them.
- yabadabadoes 7y agoMy impression on systems from the days before linux/Intel began having real SMP is that if you are willing to go off the rails completely on supporting 1-2 core machines and making every CPU available to every task, then blocking side channel attacks no longer requires all the work.. If mitigation is starting to amount to ~20%, that's roughly a CPU and soon to be 2-3, that can be told to never process directly for Userland and never tell Userland when exactly output queue contents of sensitive tasks become available. All that work essentially being free compared to running with Intel's fixes and full CPU flexibility.