Messages in this thread | | | Subject | Re: [RFC] page fault retry with NOPAGE_RETRY | From | Benjamin Herrenschmidt <> | Date | Wed, 20 Sep 2006 15:04:24 +1000 |
| |
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/
| |