4 ms·

> Otherwise, how would the kernel know you'd done it? Well, you can make a design where a submission queue spans N+1 pages, and to notify the kernel you write

> Otherwise, how would the kernel know you'd done it? Well, you can make a design where a submission queue spans N+1 pages, and to notify the kernel you write something in the last page which is actually write-protected, so it triggers the kernel trap. I believe VirtIO has a similar scheme? > What thread is actually performing that work? None? You don't need really need a user-space thread to execute code in the kernel: otherwise, starting process 1 would have to be the very first thing the kernel does when booting while in reality, that's about the last thing it does in the booting process. 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?

jclulow 2y ago
> 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.
gpderetta 2y ago
> 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? Maybe, maybe not; this would be very load dependent.
- dietr1ch 2y ago
  I feel that with different kinds of cores in newer cpus this might be a good fit for a dedicated core. Maybe a low clock speed (and low power consumption) is enough.

jclulow 2y ago

> 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.

gpderetta 2y ago

> 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? Maybe, maybe not; this would be very load dependent.

dietr1ch 2y ago
I feel that with different kinds of cores in newer cpus this might be a good fit for a dedicated core. Maybe a low clock speed (and low power consumption) is enough.