On 1/23/07, Daniel Rodrick <daniel.rodrick@xxxxxxxxx> wrote:
> > Hi, > > > > I read that ISRs can never cause a page fault. Why is that? What would > > happen if an ISR tries to use a data item that has been swapped out? > Just a guess, when page fault occurs, page fault handler is invoked > which is another ISR. This page fault handler handler does the > required stuff like bringing the data in to memory etc. This > introduces delays , and delayes are not supposed to be there in ISR. I > think when a process causes a page fault, it may sleep (and ive away > cpu to others ! ) till the page is made availabe in memory. But I > think, I am just listing out the reasons why ISR 'should not' cause > page fault. > Okay let me rephrase my question: 1) I read that an ISR cannot cause a page fault. Is the statement true? 2) In the case it is true, how are situations like this handled : an ISR tries to use a data item that has been swapped out? 3) I have the following argument that convinces me that the statement is false. When an ISR causes a page fault, the page fault handler is invoked since its priority is higher. When it finishes the control goes back to ISR, just like the normal case of nested ISR execution. Hence an ISR can cause page fault. Is any thing wrong with this argument? Thanks, Dan
The ISR code itself and the variables it talks to are locked so that page faults in an ISR can't occur (and possibly result in trashing a hard drive). Unfortunately the stack segment is not locked. It is rather unlikely that the stack would be paged out but it COULD happen. The only way to deal with this is to either have lots of RAM so paging isn't needed, or use the <crt0.h> to lock everything! This, of course, effectively disables paging generally, which is probably not a good idea for commercial code. Regards, Sandeep. -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
