Re: [RFC] page fault retry with NOPAGE_RETRY

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Tue, 2006-09-19 at 20:05 -0700, Andrew Morton wrote:

> resides in a pagetable page.  Once we've dropped mmap_sem, that
> pagetable page might not be there any more: munmap() might have freed it. 
> We have to retake mmap_sem, do a find_vma() and a new pagetable walk.
> 
> There are some optimisations we could make to avoid all of that in the
> common case, but this is the conceptual behaviour.

It's a non-issue anyway the no_page handler in Mike's patch _does_
re-take mmap_sem before returning RETRY thus my whole idea still stands
perfectly fine unless I've missed something, which means we can make it
without changing no_page arguments. Let me re-describe it:

 - somebody->no_page() returns RETRY. It may have dropped the mmap sem,
but if it did, like in Mike's patch, it will have re-taken it before
returning.

 - upon return (in handle_pte_fault typically) if we get something else
than that retry, we return 
as usual.

 - if we got RETRY we do something like

	if (signal_pending(current) || need_resched() || pte_present(*pte))
		return VM_FAULT_MINOR;
	else
		return VM_FAULT_RETRY;

Thus we still have to change arch to test for VM_FAULT_RETRY and loop on
it (or return to userland if they want but that's less optimal) but we
don't have to carry around a "MAY_RETRY" thing nor change no_page()
arguments.

The idea is that we can't livelock since we'll always schedule and we
can take signals so the process can always be killed.

We'll also avoid the loop and coming back if the PTE has been filled up
in the meantime (just a cheap optimisation avoiding a new find_vma()
etc...).

And it's simpler :)

Now, I may have missed something of course, but I'd like to know what.
So far, I don't see what won't work with the above. 

Ben.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/