On Sun, 2007-09-02 at 15:20 +0200, Nick Piggin wrote:
quoted text
> 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?

quoted text
> 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.

quoted text
> 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 that's not the end of the world, and it's not very common.

quoted text
> 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.
 
quoted text
> 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).


-- 
dwmw2

-
unsubscribe notice
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/