On Sun, Sep 02, 2007 at 02:48:04PM +0100, David Woodhouse wrote: > On Sun, 2007-09-02 at 15:20 +0200, Nick Piggin wrote: > > OK, but then hasn't the patch just made the deadlock harder to hit, > > or is there some invariant that says that readpage() will never be > > invoked if gc was invoked on the same page as we're commit_write()ing? > > > The Q/A comments aren't very sure about this. I guess from the look > > of it, prepare_write/commit_write make sure the page will be uptodate > > by the start of commit_write, > > That's the intention, yes. > > > and you avoid GCing the page in > > prepare_write because your new page won't have any nodes allocated > > yet that can possibly be GCed? > > We _might_ GC the page -- it might not be a new page; we might be > overwriting it. But it's fine if we do. Actually it's slightly > suboptimal because we'll write out the same data twice -- once in GC and > then immediately afterward in the write which we were making space for.
But doesn't GC only happen in prepare_write in the case that the i_size is being extended into a new page? If you GC the page in prepare_write (when it may be potentially !uptodate), then I'm sure you would get a deadlock when read_cache_page finds it non-uptodate and locks it for readpage(). > But that's not the end of the world, and it's not very common. > > > BTW. with write_begin/write_end, you get to control the page lock, > > so for example if the readpage in prepare_write for partial writes > > is *only* for the purpose of avoiding this deadlock later, you > > could possibly avoid the RMW with the new aops. Maybe it would > > help you with data nodes crossing page boundaries too... > > I'll look at that; thanks. OK. The patches are in -mm now, but could get in as early as 2.6.24. If you have any suggestions about the form of the APIs, it would be good to hear them. > > OK, thanks for looking at it. If you'd care to pass it on to Linus > > before he releases 2.6.23 in random() % X days time... ;) > > Not before the Kernel Summit now, I suspect. But yes, I'll do that later > today or in the morning (the linuxconf.eu conference has already > started). Thanks, - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/