Messages in this thread | | | Date | Sat, 23 Sep 2006 15:21:40 +0100 (BST) | From | Hugh Dickins <> | Subject | Re: [RFC] page fault retry with NOPAGE_RETRY |
| |
On Wed, 20 Sep 2006, Andrew Morton wrote: > On Wed, 20 Sep 2006 16:54:59 +1000 > Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote: > > > > That's what I don't understand... where is the actual race that can > > cause the livelock you are mentioning. > > Suppose a program (let's call it "DoS") is written which sits in a loop > doing fadvise(FADV_DONTNEED) against some parts of /lib/libc.so.
I agree there's an issue here, but I believe you're attacking the wrong end, thereby complicating and uglifying the pagefault path (in every arch) with your proposed arg block and retry limitation.
(Maybe one day there will be need for such an arg block, but I don't see that yet.)
Isn't the real problem that fadvise(FADV_DONTNEED) is much more powerful than it should be? Whereas madvise(MADV_DONTNEED) is simply releasing pages from my address space, fadvise(FADV_DONTNEED) is going so far as to remove them from pagecache (if nothing at that instant prevents): forcing others into I/O. Why should I be allowed to invalidate pagecache useful to others so quickly?
Shouldn't it merely, say, move the pages in its range to the inactive list, giving other processes a chance to reassert an interest in them? May not turn out as easy as that, I admit.
I'm fine with your idea of dropping mmap_sem while nopage waits on I/O, I'm fine with your idea of an mm mmap transaction count, so nopage can just reget mmap_sem without backing out when nothing changed meanwhile.
But I do think Ben should have the simple NOPAGE_RETRY he proposed, going right back out to userspace; and that should be enough for your case too (the mmap transaction count would make its use a rarity).
> So I think there's a nasty DoS here if we permit infinite retries. But > it's not just that - there might be other situations under really heavy > memory pressure where livelocks like this can occur.
filemap_nopage would want to mark_page_accessed() before returning NOPAGE_RETRY, but if that's not good enough to hold the page in cache before the retried fault grabs it, your memory pressure is already into thrashing. I believe the livelock is peculiar to FADV_DONTNEED.
Hugh - 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/
| |