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
> 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
> 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
> 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?