Rik van Riel wrote:
> 
> On Wed, 20 Sep 2000, Roger Larsson wrote:
> 
> > I added a counter for try_again loops.
> >
> > ... __alloc_pages(...)
> >
> >         int direct_reclaim = 0;
> >         unsigned int gfp_mask = zonelist->gfp_mask;
> >         struct page * page = NULL;
> > +       int try_again_loops = 0;
> >
> > - - -
> >
> > +         printk("VM: sync kswapd (direct_reclaim: %d) try_again #
> > %d\n",
> > +                direct_reclaim, ++try_again_loops);
> >                         wakeup_kswapd(1);
> >                         goto try_again;
> >
> >
> > Result was surprising:
> >   direct_reclaim was 1.
> >   try_again_loops did never stop increasing (note: it is not static,
> >   and should restart from zero after each success)
> >
> > Why does this happen?
> > a) kswapd did not succeed in freeing a suitable page?
> > b) __alloc_pages did not succeed in grabbing the page?
> 
> No.
> 
> It's a locking issue. In __alloc_pages we may be
> holding some IO locks (gfp_mask & __GFP_IO == 0),
> then we wait on kswapd and schedule out. The result is that
> kswapd will be spinning on a lock it can never get.

Hmm... If it did how could the __alloc_pages
wakeup_kswapd(1) return, it should be synchronous...
(counter is incremented past 1, a lot past...)

In addition to this I have seen that kswapd really loops with
a printk in the loop. (first in do_try_to_free_pages to be
exact)

> 
> The fix for this was included in the patch I sent to Linus
> for 2.4.0-tes9-pre2, but unfortunately not included.
> Ia'll send it agani soon.
>

Ok, I will try the patch.
But I really think that the problem is something different...
 
> There is anathor, more subtle, case like this in
> buffer.c, which I have also fixed in my local tree here.
> 
> The patch for this will be online on my home paeg
> soon. (connectivity isn't that great as you can see from mytyping)
> 
> cheers,
> 
> Rik
> --
> "What you're running that piece of shit Gnome?!?!"
>        -- Miguel de Icaza, UKUUG 2000
> 
> http://www.conectiva.com/               http://www.surriel.com/

--
Home page:
  http://www.norran.net/nra02596/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Reply via email to