Re: [PATCH] vmscan: Do reclaim stall in case of mlocked page.

[Johannes Weiner <jweiner@redhat.com>]

On Fri, Sep 02, 2011 at 11:19:49AM +0900, Minchan Kim wrote:
> On Thu, Sep 1, 2011 at 2:30 AM, Johannes Weiner <jweiner@redhat.com> wrote:
> > On Tue, Nov 15, 2011 at 12:37:23AM +0900, Minchan Kim wrote:
> >> [1] made avoid unnecessary reclaim stall when second shrink_page_list(ie, synchronous
> >> shrink_page_list) try to reclaim page_list which has not-dirty pages.
> >> But it seems rather awkawrd on unevictable page.
> >> The unevictable page in shrink_page_list would be moved into unevictable lru from page_list.
> >> So it would be not on page_list when shrink_page_list returns.
> >> Nevertheless it skips reclaim stall.
> >>
> >> This patch fixes it so that it can do reclaim stall in case of mixing mlocked pages
> >> and writeback pages on page_list.
> >>
> >> [1] 7d3579e,vmscan: narrow the scenarios in whcih lumpy reclaim uses synchrounous reclaim
> >
> > Lumpy isolates physically contiguous in the hope to free a bunch of
> > pages that can be merged to a bigger page.  If an unevictable page is
> > encountered, the chance of that is gone.  Why invest the allocation
> > latency when we know it won't pay off anymore?
> >
> 
> Good point!
> 
> Except some cases, when we require higher orer page, we used zone
> defensive algorithm by zone_watermark_ok. So the number of fewer
> higher order pages would be factor of failure of allocation. If it was
> problem, we could rescue the situation by only reclaim part of the
> block in the hope to free fewer higher order pages.

You mean if we fail to get an order-4, we may still successfully free
some order-3?

I'm not sure we should speculatively do lumpy reclaim.  If someone
wants order-3, they have to get it themselves.

> I thought the lumpy was designed to consider the case.(I might be wrong).
> Why I thought is that when we isolate the pages for lumpy and found
> the page isn't able to isolate, we don't rollback the isolated pages
> in the lumpy phsyical block. It's very pointless to get a higher order
> pages.
> 
> If we consider that, we have to fix other reset_reclaim_mode cases as
> well as mlocked pages.
> Or
> fix isolataion logic for the lumpy? (When we find the page isn't able
> to isolate, rollback the pages in the lumpy block to the LRU)
> Or
> Nothing and wait to remove lumpy completely.
> 
> What do you think about it?

The rollback may be overkill and we already abort clustering the
isolation when one of the pages fails.

I would go with the last option.  Lumpy reclaim is on its way out and
already disabled for a rather common configuration, so I would defer
non-obvious fixes like these until actual bug reports show up.