[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170118144655.3lra7xgdcl2awgjd@suse.de>
Date: Wed, 18 Jan 2017 14:46:55 +0000
From: Mel Gorman <mgorman@...e.de>
To: Michal Hocko <mhocko@...nel.org>
Cc: linux-mm@...ck.org, Johannes Weiner <hannes@...xchg.org>,
Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
LKML <linux-kernel@...r.kernel.org>,
Michal Hocko <mhocko@...e.com>
Subject: Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated pages
per zone
On Wed, Jan 18, 2017 at 02:44:52PM +0100, Michal Hocko wrote:
> From: Michal Hocko <mhocko@...e.com>
>
> 599d0c954f91 ("mm, vmscan: move LRU lists to node") has moved
> NR_ISOLATED* counters from zones to nodes. This is not the best fit
> especially for systems with high/lowmem because a heavy memory pressure
> on the highmem zone might block lowmem requests from making progress. Or
> we might allow to reclaim lowmem zone even though there are too many
> pages already isolated from the eligible zones just because highmem
> pages will easily bias too_many_isolated to say no.
>
> Fix these potential issues by moving isolated stats back to zones and
> teach too_many_isolated to consider only eligible zones. Per zone
> isolation counters are a bit tricky with the node reclaim because
> we have to track each page separatelly.
>
I'm quite unhappy with this. Each move back increases the cache footprint
because of the counters but it's not clear at all this patch actually
helps anything.
Heavy memory pressure on highmem should be spread across the whole node as
we no longer are applying the fair zone allocation policy. The processes
with highmem requirements will be reclaiming from all zones and when it
finishes, it's possible that a lowmem-specific request will be clear to make
progress. It's all the same LRU so if there are too many pages isolated,
it makes sense to wait regardless of the allocation request.
More importantly, this patch may make things worse and delay reclaim. If
this patch allowed a lowmem request to make progress that would have
previously stalled, it's going to spend time skipping pages in the LRU
instead of letting kswapd and the highmem pressured processes make progress.
--
Mel Gorman
SUSE Labs
Powered by blists - more mailing lists