Re: [PATCH] kswapd shall not sleep during page shortage

Marcelo Tosatti
2004-11-10T18:14:50Z

On Tue, Nov 09, 2004 at 04:28:01PM -0800, Andrew Morton wrote:
> Marcelo Tosatti <marcelo.tosatti@cyclades.com> wrote:
> >
> > Back to arguing in favour of my patch - it seemed to me that kswapd could
> > go to sleep leaving allocators which can't reclaim pages themselves in a
> > bad situation.
>
> Yes, but those processes would be sleeping in blk_congestion_wait() during,
> say, a GFP_NOIO/GFP_NOFS allocation attempt. And in that case, they may be
> holding locks whcih prevent kswapd from being able to do any work either.
>
> > It would have to be waken up by another instance of alloc_pages to then
> > execute and start doing its job, while if it was executing already (madly
> > scanning as you say), the chance it would find freeable pages quite
> > earlier.
> >
> > Note that not only disk IO can cause pages to become freeable. A user
> > can give up its reference on pagecache page for example (leaving
> > the page on LRU to be found and freed by kswapd).
>
> yup. Or munlock(), or direct-io completion.

Andrew,

Shouldnt the kernel ideally clear zone->all_unreclaimable in those
situations? (munlock, direct-io completion, last reference on pagecache
page, etc).