linux-kernel - Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated pages per zone

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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