[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120110165743.GE4118@suse.de>
Date: Tue, 10 Jan 2012 16:57:43 +0000
From: Mel Gorman <mgorman@...e.de>
To: Hillf Danton <dhillf@...il.com>
Cc: linux-mm@...ck.org,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
David Rientjes <rientjes@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mm: vmscan: no change of reclaim mode if unevictable
page encountered
On Wed, Jan 11, 2012 at 12:27:53AM +0800, Hillf Danton wrote:
> On Tue, Jan 10, 2012 at 5:40 PM, Mel Gorman <mgorman@...e.de> wrote:
> > On Sat, Jan 07, 2012 at 11:46:17AM +0800, Hillf Danton wrote:
> >> Since unevictable page is not isolated from lru list for shrink_page_list(),
> >> it is accident if encountered in shrinking, and no need to change reclaim mode.
> >>
> >
> > This changelog does does not explain the problem, does not explain
> > what is fixed or what the impact is.
> >
> > It also does not make sense. It says "unevictable page is not isolated
> > from LRU list" but this is shrink_page_list() and the page has already
> > been isolated (probably by lumpy reclaim). It will be put back on
> > the LRU_UNEVICTABLE list.
> >
> > It might be the case that resetting the reclaim mode after encountering
> > mlocked pages is overkill but that would need more justification than
> > what this changelog offers. Resetting the mode impacts THP rates but
> > this is erring on the side of caution by doing less work in reclaim
> > as the savings from THP may not offset the cost of reclaim.
> >
>
> Hi Mel
>
> It is reprepared, please review again.
>
> Thanks
> Hillf
>
> ===cut please===
> From: Hillf Danton <dhillf@...il.com>
> [PATCH] mm: vmscan: no change of reclaim mode if unevictable page encountered
>
> Unevictable pages are not isolated from lru list for shrink_page_list(), and
> they could be put back onto lru list if accidentally encountered in shrinking.
>
> But resetting reclaim mode maybe overkill, as it impacts THP rates. This is
> erring on the side of caution by doing less work in reclaim as the savings
> from THP may not offset the cost of reclaim.
>
When I said it needed more justification, I meant that you need to show
a workload or usecase that suffers as a result of reset_reclaim_mode
being called here. I explained already that the reset errs on the
side of caution by making reclaim work less.
You need to describe what problem your workload is suffering from and
why this patch fixes it.
--
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists