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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:25 EST