[Top] [All Lists]

Re: grab_cache_page deadlock | was Re: set_buffer_dirty_uptodate

To: Rajagopal Ananthanarayanan <ananth@xxxxxxx>
Subject: Re: grab_cache_page deadlock | was Re: set_buffer_dirty_uptodate
From: Marcelo Tosatti <marcelo@xxxxxxxxxxxxxxxx>
Date: Thu, 28 Dec 2000 16:17:41 -0200 (BRST)
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <3A4B8DB8.35A004CD@sgi.com>
Sender: owner-linux-xfs@xxxxxxxxxxx

On Thu, 28 Dec 2000, Rajagopal Ananthanarayanan wrote:

> Marcelo Tosatti wrote:
> > 
> > On Tue, 26 Dec 2000, Marcelo Tosatti wrote:
> > 
> > > The correct solution to your problem is to not pass __GFP_IO in the
> > > allocation flag passed to __alloc_pages.
> > >
> > > This way the allocation routines will not try to do any kind of IO and
> > > will not wait for kswapd.
> > >
> The problem still happens with the patch, now under a different scenario.
> The issue is that _any_ memory allocation under a FS lock can wait for
> kswapd ... and kswapd can, in turn, wait for a FS lock while pruning the 
> dcache.
> Following is a typical backtrace of  (1) kswapd (2) a process waiting for
> memory while trying to copy-in a part of user memory. Obviously, it will
> be impossible to fix all these allocations to not have GFP_IO, so an alternate
> strategy in __alloc_pages that does not wait for kswapd is one likely 
> solution.
> Another possibility is to have a seperate daemon for doing the pruning work.
> A third possibility is to let FS's iput return failure when it can't get 
> locks;
> thus avoiding kswapd to wait indefinitely.
> What do you think?

I think the only clean solution for this case is to not hold any FS lock
while we're before calling copy_from_user(). 

Is that too hard to do with current XFS code? 

<Prev in Thread] Current Thread [Next in Thread>