From: Mel Gorman <mgorman@techsingularity.net>
To: Balbir Singh <bsingharora@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Linux-MM <linux-mm@kvack.org>, Rik van Riel <riel@surriel.com>,
Vlastimil Babka <vbabka@suse.cz>,
Johannes Weiner <hannes@cmpxchg.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 00/27] Move LRU page reclaim from zones to nodes v7
Date: Fri, 24 Jun 2016 08:50:59 +0100 [thread overview]
Message-ID: <20160624075059.GC1868@techsingularity.net> (raw)
In-Reply-To: <3c062233-1ef7-bc85-5079-255f61f57c7d@gmail.com>
On Fri, Jun 24, 2016 at 04:35:45PM +1000, Balbir Singh wrote:
> > 1. The residency of a page partially depends on what zone the page was
> > allocated from. This is partially combatted by the fair zone allocation
> > policy but that is a partial solution that introduces overhead in the
> > page allocator paths.
> >
> > 2. Currently, reclaim on node 0 behaves slightly different to node 1. For
> > example, direct reclaim scans in zonelist order and reclaims even if
> > the zone is over the high watermark regardless of the age of pages
> > in that LRU. Kswapd on the other hand starts reclaim on the highest
> > unbalanced zone. A difference in distribution of file/anon pages due
> > to when they were allocated results can result in a difference in
> > again. While the fair zone allocation policy mitigates some of the
> > problems here, the page reclaim results on a multi-zone node will
> > always be different to a single-zone node.
> > it was scheduled on as a result.
> >
> > 3. kswapd and the page allocator scan zones in the opposite order to
> > avoid interfering with each other but it's sensitive to timing. This
> > mitigates the page allocator using pages that were allocated very recently
> > in the ideal case but it's sensitive to timing. When kswapd is allocating
> > from lower zones then it's great but during the rebalancing of the highest
> > zone, the page allocator and kswapd interfere with each other. It's worse
> > if the highest zone is small and difficult to balance.
> >
> > 4. slab shrinkers are node-based which makes it harder to identify the exact
> > relationship between slab reclaim and LRU reclaim.
> >
>
> Sorry, I am late in reading the thread and the patches, but I am trying to understand
> the key benefits?
The key benefits were outlined at the beginning of the changelog. The
one that is missing is the large overhead from the fair zone allocation
policy which can be removed safely by the feature. The benefit to page
allocator micro-benchmarks is outlined in the series introduction.
> I know that
> zones have grown to be overloaded to mean many things now. What is the contention impact
> of moving the LRU from zone to nodes?
Expected to be minimal. On NUMA machines, most nodes have only one zone.
On machines with multiple zones, the lock per zone is not that fine-grained
given the size of the zones on large memory configurations.
--
Mel Gorman
SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mgorman@techsingularity.net>
To: Balbir Singh <bsingharora@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Linux-MM <linux-mm@kvack.org>, Rik van Riel <riel@surriel.com>,
Vlastimil Babka <vbabka@suse.cz>,
Johannes Weiner <hannes@cmpxchg.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 00/27] Move LRU page reclaim from zones to nodes v7
Date: Fri, 24 Jun 2016 08:50:59 +0100 [thread overview]
Message-ID: <20160624075059.GC1868@techsingularity.net> (raw)
In-Reply-To: <3c062233-1ef7-bc85-5079-255f61f57c7d@gmail.com>
On Fri, Jun 24, 2016 at 04:35:45PM +1000, Balbir Singh wrote:
> > 1. The residency of a page partially depends on what zone the page was
> > allocated from. This is partially combatted by the fair zone allocation
> > policy but that is a partial solution that introduces overhead in the
> > page allocator paths.
> >
> > 2. Currently, reclaim on node 0 behaves slightly different to node 1. For
> > example, direct reclaim scans in zonelist order and reclaims even if
> > the zone is over the high watermark regardless of the age of pages
> > in that LRU. Kswapd on the other hand starts reclaim on the highest
> > unbalanced zone. A difference in distribution of file/anon pages due
> > to when they were allocated results can result in a difference in
> > again. While the fair zone allocation policy mitigates some of the
> > problems here, the page reclaim results on a multi-zone node will
> > always be different to a single-zone node.
> > it was scheduled on as a result.
> >
> > 3. kswapd and the page allocator scan zones in the opposite order to
> > avoid interfering with each other but it's sensitive to timing. This
> > mitigates the page allocator using pages that were allocated very recently
> > in the ideal case but it's sensitive to timing. When kswapd is allocating
> > from lower zones then it's great but during the rebalancing of the highest
> > zone, the page allocator and kswapd interfere with each other. It's worse
> > if the highest zone is small and difficult to balance.
> >
> > 4. slab shrinkers are node-based which makes it harder to identify the exact
> > relationship between slab reclaim and LRU reclaim.
> >
>
> Sorry, I am late in reading the thread and the patches, but I am trying to understand
> the key benefits?
The key benefits were outlined at the beginning of the changelog. The
one that is missing is the large overhead from the fair zone allocation
policy which can be removed safely by the feature. The benefit to page
allocator micro-benchmarks is outlined in the series introduction.
> I know that
> zones have grown to be overloaded to mean many things now. What is the contention impact
> of moving the LRU from zone to nodes?
Expected to be minimal. On NUMA machines, most nodes have only one zone.
On machines with multiple zones, the lock per zone is not that fine-grained
given the size of the zones on large memory configurations.
--
Mel Gorman
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2016-06-24 7:51 UTC|newest]
Thread overview: 124+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-21 14:15 [PATCH 00/27] Move LRU page reclaim from zones to nodes v7 Mel Gorman
2016-06-21 14:15 ` Mel Gorman
2016-06-21 14:15 ` [PATCH 01/27] mm, vmstat: Add infrastructure for per-node vmstats Mel Gorman
2016-06-21 14:15 ` Mel Gorman
2016-06-21 14:15 ` [PATCH 02/27] mm, vmscan: Move lru_lock to the node Mel Gorman
2016-06-21 14:15 ` Mel Gorman
2016-06-21 14:15 ` [PATCH 03/27] mm, vmscan: Move LRU lists to node Mel Gorman
2016-06-21 14:15 ` Mel Gorman
2016-06-22 12:50 ` Vlastimil Babka
2016-06-22 12:50 ` Vlastimil Babka
2016-06-21 14:15 ` [PATCH 04/27] mm, vmscan: Begin reclaiming pages on a per-node basis Mel Gorman
2016-06-21 14:15 ` Mel Gorman
2016-06-22 14:04 ` Vlastimil Babka
2016-06-22 14:04 ` Vlastimil Babka
2016-06-22 16:00 ` Vlastimil Babka
2016-06-22 16:00 ` Vlastimil Babka
2016-06-23 11:07 ` Mel Gorman
2016-06-23 11:07 ` Mel Gorman
2016-06-23 11:13 ` Michal Hocko
2016-06-23 11:13 ` Michal Hocko
2016-06-23 10:58 ` Mel Gorman
2016-06-23 10:58 ` Mel Gorman
2016-06-21 14:15 ` [PATCH 05/27] mm, vmscan: Have kswapd only scan based on the highest requested zone Mel Gorman
2016-06-21 14:15 ` Mel Gorman
2016-06-21 14:15 ` [PATCH 06/27] mm, vmscan: Make kswapd reclaim in terms of nodes Mel Gorman
2016-06-21 14:15 ` Mel Gorman
2016-06-21 14:15 ` [PATCH 07/27] mm, vmscan: Remove balance gap Mel Gorman
2016-06-21 14:15 ` Mel Gorman
2016-06-21 14:15 ` [PATCH 08/27] mm, vmscan: Simplify the logic deciding whether kswapd sleeps Mel Gorman
2016-06-21 14:15 ` Mel Gorman
2016-06-22 15:30 ` Vlastimil Babka
2016-06-22 15:30 ` Vlastimil Babka
2016-06-21 14:15 ` [PATCH 09/27] mm, vmscan: By default have direct reclaim only shrink once per node Mel Gorman
2016-06-21 14:15 ` Mel Gorman
2016-06-21 14:15 ` [PATCH 10/27] mm, vmscan: Remove duplicate logic clearing node congestion and dirty state Mel Gorman
2016-06-21 14:15 ` Mel Gorman
2016-06-21 14:15 ` [PATCH 11/27] mm: vmscan: Do not reclaim from kswapd if there is any eligible zone Mel Gorman
2016-06-21 14:15 ` Mel Gorman
2016-06-21 14:15 ` [PATCH 12/27] mm, vmscan: Make shrink_node decisions more node-centric Mel Gorman
2016-06-21 14:15 ` Mel Gorman
2016-06-22 13:20 ` Michal Hocko
2016-06-22 13:20 ` Michal Hocko
2016-06-22 15:42 ` Vlastimil Babka
2016-06-22 15:42 ` Vlastimil Babka
2016-06-21 14:15 ` [PATCH 13/27] mm, memcg: Move memcg limit enforcement from zones to nodes Mel Gorman
2016-06-21 14:15 ` Mel Gorman
2016-06-22 13:15 ` Michal Hocko
2016-06-22 13:15 ` Michal Hocko
2016-06-21 14:15 ` [PATCH 14/27] mm, workingset: Make working set detection node-aware Mel Gorman
2016-06-21 14:15 ` Mel Gorman
2016-06-21 14:15 ` [PATCH 15/27] mm, page_alloc: Consider dirtyable memory in terms of nodes Mel Gorman
2016-06-21 14:15 ` Mel Gorman
2016-06-22 14:15 ` Michal Hocko
2016-06-22 14:15 ` Michal Hocko
2016-06-22 14:27 ` Michal Hocko
2016-06-22 14:27 ` Michal Hocko
2016-06-23 12:53 ` Mel Gorman
2016-06-23 12:53 ` Mel Gorman
2016-06-23 13:13 ` Michal Hocko
2016-06-23 13:13 ` Michal Hocko
2016-06-21 14:15 ` [PATCH 16/27] mm: Move page mapped accounting to the node Mel Gorman
2016-06-21 14:15 ` Mel Gorman
2016-06-21 22:32 ` Andrew Morton
2016-06-21 22:32 ` Andrew Morton
2016-06-23 8:35 ` Mel Gorman
2016-06-23 8:35 ` Mel Gorman
2016-06-22 14:35 ` Michal Hocko
2016-06-22 14:35 ` Michal Hocko
2016-06-21 14:15 ` [PATCH 17/27] mm: Rename NR_ANON_PAGES to NR_ANON_MAPPED Mel Gorman
2016-06-21 14:15 ` Mel Gorman
2016-06-22 14:28 ` Michal Hocko
2016-06-22 14:28 ` Michal Hocko
2016-06-21 14:15 ` [PATCH 18/27] mm: Move most file-based accounting to the node Mel Gorman
2016-06-21 14:15 ` Mel Gorman
2016-06-22 14:38 ` Michal Hocko
2016-06-22 14:38 ` Michal Hocko
2016-06-21 14:15 ` [PATCH 19/27] mm: Move vmscan writes and file write " Mel Gorman
2016-06-21 14:15 ` Mel Gorman
2016-06-22 14:40 ` Michal Hocko
2016-06-22 14:40 ` Michal Hocko
2016-06-23 13:57 ` Mel Gorman
2016-06-23 13:57 ` Mel Gorman
2016-06-23 14:06 ` Vlastimil Babka
2016-06-23 14:06 ` Vlastimil Babka
2016-06-23 16:03 ` Mel Gorman
2016-06-23 16:03 ` Mel Gorman
2016-06-21 14:15 ` [PATCH 20/27] mm, vmscan: Update classzone_idx if buffer_heads_over_limit Mel Gorman
2016-06-21 14:15 ` Mel Gorman
2016-06-22 14:49 ` Michal Hocko
2016-06-22 14:49 ` Michal Hocko
2016-06-21 14:16 ` [PATCH 21/27] mm, vmscan: Only wakeup kswapd once per node for the requested classzone Mel Gorman
2016-06-21 14:16 ` Mel Gorman
2016-06-22 16:08 ` Vlastimil Babka
2016-06-22 16:08 ` Vlastimil Babka
2016-06-21 14:16 ` [PATCH 22/27] mm: Convert zone_reclaim to node_reclaim Mel Gorman
2016-06-21 14:16 ` Mel Gorman
2016-06-21 14:16 ` [PATCH 23/27] mm, vmscan: Add classzone information to tracepoints Mel Gorman
2016-06-21 14:16 ` Mel Gorman
2016-06-21 14:16 ` [PATCH 24/27] mm, page_alloc: Remove fair zone allocation policy Mel Gorman
2016-06-21 14:16 ` Mel Gorman
2016-06-21 14:16 ` [PATCH 25/27] mm: page_alloc: Cache the last node whose dirty limit is reached Mel Gorman
2016-06-21 14:16 ` Mel Gorman
2016-06-21 14:16 ` [PATCH 26/27] mm: vmstat: Replace __count_zone_vm_events with a zone id equivalent Mel Gorman
2016-06-21 14:16 ` Mel Gorman
2016-06-21 14:16 ` [PATCH 27/27] mm: vmstat: Account per-zone stalls and pages skipped during reclaim Mel Gorman
2016-06-21 14:16 ` Mel Gorman
2016-06-23 10:26 ` [PATCH 00/27] Move LRU page reclaim from zones to nodes v7 Mel Gorman
2016-06-23 10:26 ` Mel Gorman
2016-06-23 11:27 ` Michal Hocko
2016-06-23 11:27 ` Michal Hocko
2016-06-23 12:33 ` Mel Gorman
2016-06-23 12:33 ` Mel Gorman
2016-06-23 12:44 ` Michal Hocko
2016-06-23 12:44 ` Michal Hocko
2016-06-23 21:45 ` Andrew Morton
2016-06-23 21:45 ` Andrew Morton
2016-06-24 6:35 ` Balbir Singh
2016-06-24 6:35 ` Balbir Singh
2016-06-24 7:50 ` Mel Gorman [this message]
2016-06-24 7:50 ` Mel Gorman
2016-06-27 12:48 ` Balbir Singh
2016-06-27 12:48 ` Balbir Singh
-- strict thread matches above, loose matches on Subject: below --
2016-06-21 11:43 Mel Gorman
2016-06-21 11:43 ` Mel Gorman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160624075059.GC1868@techsingularity.net \
--to=mgorman@techsingularity.net \
--cc=akpm@linux-foundation.org \
--cc=bsingharora@gmail.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=riel@surriel.com \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.