Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1561893

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

From Michal Hocko <mhocko@kernel.org>
Newsgroups linux.kernel
Subject Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated pages per zone
Date 2017-01-18 16:20 +0100
Message-ID <t10bN-5IB-39@gated-at.bofh.it> (permalink)
References <t0YWl-4Nd-15@gated-at.bofh.it> <t0YWm-4Nd-21@gated-at.bofh.it> <t0ZIJ-5ji-9@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Wed 18-01-17 14:46:55, Mel Gorman wrote:
> On Wed, Jan 18, 2017 at 02:44:52PM +0100, Michal Hocko wrote:
> > From: Michal Hocko <mhocko@suse.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

Why would per zone counters cause an increased cache footprint?

> but it's not clear at all this patch actually helps anything.

Yes, I cannot prove any real issue so far. The main motivation was the
patch 2 which needs per-zone accounting to use it in the retry logic
(should_reclaim_retry). I've spotted too_many_isoalated issues on the
way.

> 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.

This is true but I am not sure how it is realated to the patch. If we
have a heavy highmem memory pressure then we will throttle based on
pages isolated from the respective zones. So if the there is a lowmem
pressure at the same time then we throttle it only when we need to.

Also consider that lowmem throttling in too_many_isolated has only small
chance to ever work with the node counters because highmem >> lowmem in
many/most configurations.

> 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.

I am not sure I understand this part. Say that we have highmem pressure
which would isolated too many pages from the LRU. lowmem request would
stall previously regardless of where those pages came from. With this
patch it would stall only when we isolated too many pages from the
eligible zones. So let's assume that lowmem is not under pressure, why
should we stall? And why would it delay reclaim? Whoever want to make
progress on that zone has to iterate and potentially skip many pages.
-- 
Michal Hocko
SUSE Labs

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[RFC PATCH 0/2] fix unbounded too_many_isolated Michal Hocko <mhocko@kernel.org> - 2017-01-18 15:00 +0100
  [RFC PATCH 1/2] mm, vmscan: account the number of isolated pages per zone Michal Hocko <mhocko@kernel.org> - 2017-01-18 15:00 +0100
    Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated pages  per zone Mel Gorman <mgorman@suse.de> - 2017-01-18 15:50 +0100
      Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated pages  per zone Michal Hocko <mhocko@kernel.org> - 2017-01-18 16:20 +0100
        Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated pages  per zone Mel Gorman <mgorman@suse.de> - 2017-01-18 17:00 +0100
          Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated pages  per zone Michal Hocko <mhocko@kernel.org> - 2017-01-18 17:20 +0100
            Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated pages  per zone Mel Gorman <mgorman@suse.de> - 2017-01-18 18:10 +0100
              Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated pages  per zone Michal Hocko <mhocko@kernel.org> - 2017-01-18 18:30 +0100
                Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated pages  per zone Mel Gorman <mgorman@suse.de> - 2017-01-19 11:10 +0100
                Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated pages  per zone Michal Hocko <mhocko@kernel.org> - 2017-01-19 12:50 +0100
                Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated pages  per zone Mel Gorman <mgorman@suse.de> - 2017-01-19 14:20 +0100
                Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated pages per zone Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2017-01-20 15:20 +0100
                Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated pages per zone Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2017-01-21 08:50 +0100
                Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated pages  per zone Michal Hocko <mhocko@kernel.org> - 2017-01-25 11:20 +0100
                Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated         pages per zone Christoph Hellwig <hch@lst.de> - 2017-01-25 11:30 +0100
                Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated pages  per zone Michal Hocko <mhocko@kernel.org> - 2017-01-25 11:50 +0100
                Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated pages per zone Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2017-01-25 12:20 +0100
                Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated pages  per zone Michal Hocko <mhocko@kernel.org> - 2017-01-25 14:10 +0100
                Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated pages  per zone Michal Hocko <mhocko@kernel.org> - 2017-01-27 16:00 +0100
                Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated pages per zone Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2017-01-28 18:20 +0100
                Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated pages  per zone Michal Hocko <mhocko@kernel.org> - 2017-01-30 10:00 +0100
                Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated pagesper zone Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2017-01-25 11:40 +0100
                Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated  pagesper zone Michal Hocko <mhocko@kernel.org> - 2017-01-25 13:40 +0100
                Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated pages per zone Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2017-01-25 14:20 +0100
                Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated pages  per zone Michal Hocko <mhocko@kernel.org> - 2017-01-25 11:00 +0100
                Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated pages per zone "Hillf Danton" <hillf.zj@alibaba-inc.com> - 2017-01-20 07:50 +0100
                Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated pages  per zone Mel Gorman <mgorman@suse.de> - 2017-01-20 10:30 +0100

csiph-web