On Thu, 28 Dec 2000, Andi Kleen wrote:
> On Thu, Dec 28, 2000 at 11:00:08AM -0800, 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.
>
> The separate daemon (kiod) has just been removed from 2.2 because it was
> broken -- it prevents write throttling for memory hooks, causing spurious
> oom conditions.
>
> Andrea Arcangelli (cc'ed) did that work for 2.2, perhaps he can suggest a good
> solution for 2.4/XFS too.
Indeed.
Basically what Andrea did in 2.2 was to add a "has_io_locks" flag to the
task_struct structure which indicates if the current process has any fs
lock held. (the flag is increased when any fs lock is taken, and decreased
when any fs lock is unlocked)
With this scheme its possible to not sleep on kswapd if we have
"current->has_io_locks" > 0 and avoid the deadlock.
Ananth, what do you think about this fix?
|