On Thursday, December 20, 2001 09:44:52 PM -0800 Andrew Morton
<akpm@zip.com.au> wrote:
> Chris Mason wrote:
>>
>> Ok, I'm ignoring the shrink_dcache issue I mentioned earlier today
>> for the moment. It has not shown up in any of the traces from Johan's
>> machines, and I'd like to get his problems fixed before moving on to
>> the (much) rarer iput problems.
>>
>
> OK, looks like it'll fix the problem. Which you previously described
> as:
Hi Andrew, thanks for giving this a look.
> A similar deadlock could occur at writepage(). ext3 goes to some
> lengths to avoid blocking on the journal at writepage - if the caller
> is PF_MEMALLOC and we can't unblockingly start a transaction we redirty
> the page and bale.
>
> It seems that reiserfs can also start a transaction at writepage. How
> come it doesn't deadlock there?
I've got patches for this too, I'll them integrated after new year's. It
seems like the quota semaphore makes the deadlock much more likely with the
quota code.
>
> A couple of broad-sweep things:
>
> - The VM refuses to write out swapcached pages when called without
> __GFP_FS. For swap devices (as opposed to swapfiles), it appears
> that we could in fact perform the swapout, which would help, but
> not cure this.
Yes.
>
> - Where's bdflush? It should be madly undirtying pages and making
> the situation better.
bdflush can flush the dirty buffers on the dirty pages, but it leaves the
page dirty. I almost think we should move the decision about writing the
page under GFP_NOFS to the filesystem (2.5.x). If the buffers are already
mapped, the page can be written without taking any FS locks at all.
>
> Neither of which fix the problem with mapped files. Bring on
> kinoded, I guess. Maybe. Did you think about just kicking kupdate
> and letting it sync the inodes?
The current kupdate won't touch the unused inode list, and we dive into the
quota code while calling clear_inode while freeing unused inodes. I could
change kupdate to do what kinoded does, but then kupdate moves away from
being a periodic flusher and changes into something that responds to memory
pressure.
-chris
-
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/
This archive was generated by hypermail 2b29 : Sun Dec 23 2001 - 21:00:24 EST