> notify the kernel you write something in the last page which is actually write-protected, so it triggers the kernel trap Right, that's a page fault; i.e., a

> notify the kernel you write something in the last page which is actually write-protected, so it triggers the kernel trap Right, that's a page fault; i.e., a context and privilege level switch. I can't imagine that's going to be any cheaper than a system call. > None? You don't need really need a user-space thread to execute code in the kernel I didn't mention user space. There are threads in the kernel. From a scheduling perspective, somebody needs to be billed for the work they're doing. If it's not the process that invoked the system call, that seems like a pretty easy way to induce a bunch of noisy work on the system in excess of what the regular scheduling algorithm and resource capping would allow. > With multi-core systems we have today, arguably having a whole core dedicated exclusively for some core OS functionality could be more performant than having this core "constantly" switch contexts? Perhaps! Without a design and some measurement it seems impossible to know. Logically, though, you'll still have (kernel) threads of some kind executing in that special partition. They'll compete for execution time, just like user mode threads compete for execution time, at which point for fairness you'll have to figure out how to bill the work back to the user process somehow.