Dynamically sizing the kernel stack

Posted May 21, 2024 18:27 UTC (Tue) by epa (subscriber, #39769)
In reply to: Dynamically sizing the kernel stack by josh
Parent article: Dynamically sizing the kernel stack

I was surprised to learn that handling a page fault can itself trigger a page fault. (If you could guarantee that the page fault handler didn't need to be re-entrant, then it wouldn't need to use the stack, but could have a small dedicated memory area per processor.) I guess it makes sense on complex modern systems that faulting in a page from swap space (for example) might itself perform filesystem or device driver operations that need to allocate.

to post comments

Dynamically sizing the kernel stack

Posted May 21, 2024 18:49 UTC (Tue) by matthias (subscriber, #94967) [Link]

Of course, this can be arbitrarily complex. Swap space is still quite simple. Just think of faulting in a page from a memory-mapped file that lives in some FUSE filesystem. So you might actually need to wait for another user space process.

But it is not necessary to think that complicated. Faulting in a page just from swap takes ages (even with SSDs). Thus you want to yield to another thread. And the other thread might also have a page fault while you are still waiting for the first page. So even for the simplest of cases you really want the fault handler to be re-entrant.

Dynamically sizing the kernel stack

Posted May 21, 2024 20:24 UTC (Tue) by kleptog (subscriber, #1183) [Link]

It gets worse. A page fault in a VM can trigger multiple page faults in the hypervisor. Page tables themselves can also be swapped out. It is possible for fault handler to declare their own stack, but that's just shifting the problem.