Peter Teoh wrote:
On Wed, Jul 23, 2008 at 6:55 AM, Rik van Riel <riel@xxxxxxxxxxx> wrote:
On Tue, 22 Jul 2008 23:28:01 +0200
ninjaboy <n0b0dyn1nj4@xxxxxxxxx> wrote:
2008/7/22 Rik van Riel <riel@xxxxxxxxxxx>:
On Tue, 22 Jul 2008 13:51:43 -0400
Arn <cse.syslab@xxxxxxxxx> wrote:
So I assume that when a major fault happens, somehow get_user_pages()
gets called, is that correct ?
No. When a page fault happens, handle_mm_fault() is called.
The get_user_pages() path is when kernel code tries to access
the pages of a process that is not the current process.
why kernel tries to access the page of a process that is not the
current process?
Think about attaching a debugger to a userspace process and
trying to peek or poke the memory of the process.
The debugger may try to access memory that is currently
swapped out, which will cause the memory to get swapped in.
Is this the only scenario that can happen?
I believe it may also happen if a new process with a high priority
enters the run queue and in order to malloc() RAM for it, a soon to be
run or just run process of a lower priority has to be swapped out from
the run queue. I'm just guessing, but IIRC, most *NIX schedulers will
swap out a runnable task if a new higher priority task enters the
system and needs the memory. That leaves it in a ready/runnable state
while 'on ice' so far as its memory pages go. Please correct me if I'm
wrong, it's 5AM here :)
|
