Re: [PATCH 07/10] mm: vmscan: Block kswapd if it is encounteringpages under writeback

[Mel Gorman]

On Sun, Mar 17, 2013 at 07:49:50AM -0700, Andi Kleen wrote:
> Mel Gorman <mgorman@xxxxxxx> writes:
> 
> 
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index 493728b..7d5a932 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -725,6 +725,19 @@ static unsigned long shrink_page_list(struct list_head *page_list,
> >  
> >  		if (PageWriteback(page)) {
> >  			/*
> > +			 * If reclaim is encountering an excessive number of
> > +			 * pages under writeback and this page is both under
> > +			 * writeback and PageReclaim then it indicates that
> > +			 * pages are being queued for IO but are being
> > +			 * recycled through the LRU before the IO can complete.
> > +			 * is useless CPU work so wait on the IO to complete.
> > +			 */
> > +			if (current_is_kswapd() &&
> > +			    zone_is_reclaim_writeback(zone)) {
> > +				wait_on_page_writeback(page);
> > +				zone_clear_flag(zone, ZONE_WRITEBACK);
> > +
> > +			/*
> 
> Something is wrong with the indentation here. Comment should be indented
> or is the code in the wrong block?
> 

I'll rearrange the comments.

> It's not fully clair to me how you decide here that the writeback
> situation has cleared. There must be some kind of threshold for it,
> but I don't see it. Or do you clear already when the first page
> finished? That would seem too early.
> 

I deliberately cleared it when the first page finished.  If kswapd blocks
waiting for IO of that page to complete then it cannot be certain that
there are still too many pages at the end of the LRU. By clearing the
flag, it's forced to recheck instead of potentially blocking on the next
page unnecessarily.

What I did get wrong is that I meant to check PageReclaim here as
described in the comment. It must have gotten lost during a rebase.

> BTW longer term the code would probably be a lot clearer with a
> real explicit state machine instead of all these custom state bits.
> 

I would expect so even though it'd be a major overhawl.

-- 
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/