6 ms·

You might be able to do that in response to a system call asking whether a memory page is available, but not in response to a page fault. A page fault occurs if

You might be able to do that in response to a system call asking whether a memory page is available, but not in response to a page fault. A page fault occurs if the process tries to access a virtual memory page that's not currently mapped to physical memory. Unless I'm missing something, the only reasonable way of resuming the process at the machine code instruction that caused the page fault is to first make sure the memory is available. Otherwise you will simply get another page fault.

dllthomas 10y ago
You don't necessarily need to resume the process at the machine code instruction that caused the page fault.
- smarnach 10y ago
  Right, you also have the option of not resuming it at all.
  - dllthomas 10y ago
    I mean in principle, you could resume in another place. That's what's being done if you register a handler for SIGSEGV, for instance. Not that there's much you can do there, with existing programming models.
smegel 10y ago
1. thread: hey kernel, I would like to read this page of memory. 2. kernel: hey thread, that page is still on SLOOOOW spinning disk, why don't you go off and do something else while I get it for you. I'll let you know with an event notification, so be sure to check in with kqueue regularly. 3. thread: OK then, i'll go off and serve these other people while you do that for me. kthanx. 4. kernel: hey DMA controller, I'd like you to get sectors 4, 5 and 6 from platter 3 on HDD 2 and load them into memory address 0x4fe6bb. Please send me an interrupt when done. 5. DMA controller: OK servo, please adjust read head to this offset. Read head, read me those bytes. Memory controller, please store bytes at address 0x4fe6bb. Hey CPU, here's an interrupt to store in your interrupt table, please wake up the kernel guy and let him know. 6. kernel: wow I just got interrupted. The interrupt seems to map to a request for data from this particular thread. Better let him know. (sends event up thread's kqueue). 7. thread: hey, I just got a kqueue notification that the file is now ready to be read. That means it must be in memory...cool! Make sense now?
- smarnach 10y ago
  I get that you can do this in response to a system call (the one issued in step 1). You could avoid blocking in Linux as well using madvice() and mincore(), as pointed out in the comments to the article. However, once you get an actual page fault, the only option is to block the process.
  - smegel 10y ago
    > I get that you can do this in response to a system call (the one issued in step 1). You could avoid blocking in Linux as well using madvice() and mincore() Yes, but the one thing they don't give you is notification the data is in memory. Do you really want to spin a hot loop calling mincore? > However, once you get an actual page fault, the only option is to block the process. See steps 1-3 again.
    - lgunsch 10y ago
      The only way to receive an event would be from a signal, like SIGSEGV. There is no way to hook a jump instruction up to kqueue. In any case, this would mean writing specific code to handle the case, implying it is not simply a difference of the FreeBSD kernel vs the Linux kernel.
- twic 10y ago
  This is roughly what 'scheduler activations' and 'kernel scheduled entities' did. Except rather than just being in response to page faults, it was any interaction with the kernel that would block.

dllthomas 10y ago

You don't necessarily need to resume the process at the machine code instruction that caused the page fault.

smarnach 10y ago
Right, you also have the option of not resuming it at all.
- dllthomas 10y ago
  I mean in principle, you could resume in another place. That's what's being done if you register a handler for SIGSEGV, for instance. Not that there's much you can do there, with existing programming models.

smegel 10y ago

1. thread: hey kernel, I would like to read this page of memory. 2. kernel: hey thread, that page is still on SLOOOOW spinning disk, why don't you go off and do something else while I get it for you. I'll let you know with an event notification, so be sure to check in with kqueue regularly. 3. thread: OK then, i'll go off and serve these other people while you do that for me. kthanx. 4. kernel: hey DMA controller, I'd like you to get sectors 4, 5 and 6 from platter 3 on HDD 2 and load them into memory address 0x4fe6bb. Please send me an interrupt when done. 5. DMA controller: OK servo, please adjust read head to this offset. Read head, read me those bytes. Memory controller, please store bytes at address 0x4fe6bb. Hey CPU, here's an interrupt to store in your interrupt table, please wake up the kernel guy and let him know. 6. kernel: wow I just got interrupted. The interrupt seems to map to a request for data from this particular thread. Better let him know. (sends event up thread's kqueue). 7. thread: hey, I just got a kqueue notification that the file is now ready to be read. That means it must be in memory...cool! Make sense now?

smarnach 10y ago
I get that you can do this in response to a system call (the one issued in step 1). You could avoid blocking in Linux as well using madvice() and mincore(), as pointed out in the comments to the article. However, once you get an actual page fault, the only option is to block the process.
- smegel 10y ago
  > I get that you can do this in response to a system call (the one issued in step 1). You could avoid blocking in Linux as well using madvice() and mincore() Yes, but the one thing they don't give you is notification the data is in memory. Do you really want to spin a hot loop calling mincore? > However, once you get an actual page fault, the only option is to block the process. See steps 1-3 again.
  - lgunsch 10y ago
    The only way to receive an event would be from a signal, like SIGSEGV. There is no way to hook a jump instruction up to kqueue. In any case, this would mean writing specific code to handle the case, implying it is not simply a difference of the FreeBSD kernel vs the Linux kernel.
twic 10y ago
This is roughly what 'scheduler activations' and 'kernel scheduled entities' did. Except rather than just being in response to page faults, it was any interaction with the kernel that would block.