From: Mel Gorman <mgorman@techsingularity.net>
To: Minchan Kim <minchan@kernel.org>
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/31] Move LRU page reclaim from zones to nodes v8
Date: Mon, 4 Jul 2016 05:34:05 +0100 [thread overview]
Message-ID: <20160704043405.GB11498@techsingularity.net> (raw)
In-Reply-To: <20160704013703.GA19943@bbox>
On Mon, Jul 04, 2016 at 10:37:03AM +0900, Minchan Kim wrote:
> > The reason we have zone-based reclaim is that we used to have
> > large highmem zones in common configurations and it was necessary
> > to quickly find ZONE_NORMAL pages for reclaim. Today, this is much
> > less of a concern as machines with lots of memory will (or should) use
> > 64-bit kernels. Combinations of 32-bit hardware and 64-bit hardware are
> > rare. Machines that do use highmem should have relatively low highmem:lowmem
> > ratios than we worried about in the past.
>
> Hello Mel,
>
> I agree the direction absolutely. However, I have a concern on highmem
> system as you already mentioned.
>
> Embedded products still use 2 ~ 3 ratio (highmem:lowmem).
> In such system, LRU churning by skipping other zone pages frequently
> might be significant for the performance.
>
> How big ratio between highmem:lowmem do you think a problem?
>
That's a "how long is a piece of string" type question. The ratio does
not matter as much as whether the workload is both under memory pressure
and requires large amounts of lowmem pages. Even on systems with very high
ratios, it may not be a problem if HIGHPTE is enabled.
> >
> > Conceptually, moving to node LRUs should be easier to understand. The
> > page allocator plays fewer tricks to game reclaim and reclaim behaves
> > similarly on all nodes.
> >
> > The series has been tested on a 16 core UMA machine and a 2-socket 48
> > core NUMA machine. The UMA results are presented in most cases as the NUMA
> > machine behaved similarly.
>
> I guess you would already test below with various highmem system(e.g.,
> 2:1, 3:1, 4:1 and so on). If you have, could you mind sharing it?
>
I haven't that data, the baseline distribution used doesn't even have
32-bit support. Even if it was, the results may not be that interesting.
The workloads used were not necessarily going to trigger lowmem pressure
as HIGHPTE was set on the 32-bit configs.
The skip logic has been checked and it does work. This was done during
development, by forcing the "wrong" reclaim index to use. It was
noticable in system CPU usage and in the "skip" stats. I didn't preserve
this data.
> > 4.7.0-rc4 4.7.0-rc4
> > mmotm-20160623nodelru-v8
> > Minor Faults 645838 644036
> > Major Faults 573 593
> > Swap Ins 0 0
> > Swap Outs 0 0
> > Allocation stalls 24 0
> > DMA allocs 0 0
> > DMA32 allocs 46041453 44154171
> > Normal allocs 78053072 79865782
> > Movable allocs 0 0
> > Direct pages scanned 10969 54504
> > Kswapd pages scanned 93375144 93250583
> > Kswapd pages reclaimed 93372243 93247714
> > Direct pages reclaimed 10969 54504
> > Kswapd efficiency 99% 99%
> > Kswapd velocity 13741.015 13711.950
> > Direct efficiency 100% 100%
> > Direct velocity 1.614 8.014
> > Percentage direct scans 0% 0%
> > Zone normal velocity 8641.875 13719.964
> > Zone dma32 velocity 5100.754 0.000
> > Zone dma velocity 0.000 0.000
> > Page writes by reclaim 0.000 0.000
> > Page writes file 0 0
> > Page writes anon 0 0
> > Page reclaim immediate 37 54
> >
> > kswapd activity was roughly comparable. There were differences in direct
> > reclaim activity but negligible in the context of the overall workload
> > (velocity of 8 pages per second with the patches applied, 1.6 pages per
> > second in the baseline kernel).
>
> Hmm, nodelru's allocation stall is zero above but how does direct page
> scanning/reclaimed happens?
>
Good spot, it's because I used the wrong comparison script -- one that
doesn't understand the different skip and allocation stats and I was
looking primarily at the scanning activity. This is a correct version
4.7.0-rc4 4.7.0-rc4
mmotm-20160623nodelru-v8r26
Minor Faults 645838 643815
Major Faults 573 493
Swap Ins 0 0
Swap Outs 0 0
DMA allocs 0 0
DMA32 allocs 46041453 44174923
Normal allocs 78053072 79816443
Movable allocs 0 0
Allocation stalls 24 31
Stall zone DMA 0 0
Stall zone DMA32 0 0
Stall zone Normal 0 1
Stall zone HighMem 0 0
Stall zone Movable 0 30
Direct pages scanned 10969 14198
Kswapd pages scanned 93375144 93252534
Kswapd pages reclaimed 93372243 93249856
Direct pages reclaimed 10969 14198
Kswapd efficiency 99% 99%
Kswapd velocity 13741.015 13742.771
Direct efficiency 100% 100%
Direct velocity 1.614 2.092
Percentage direct scans 0% 0%
Page writes by reclaim 0 0
Page writes file 0 0
Page writes anon 0 0
Page reclaim immediate 37 29
The points about kswapd and direct reclaim activity still hold.
> Above, DMA32 allocs in nodelru is almost same but zone dma32 velocity
> is zero. What does it means?
>
It's a consequence of using the wrong script when cutting and pasting
the final data. With node-lru, "zone dma32 velocity" is meaningless and
the reporting script no longer includes it.
--
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-07-04 4:34 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-01 20:01 [PATCH 00/31] Move LRU page reclaim from zones to nodes v8 Mel Gorman
2016-07-01 20:01 ` [PATCH 01/31] mm, vmstat: add infrastructure for per-node vmstats Mel Gorman
2016-07-04 23:50 ` Minchan Kim
2016-07-05 8:14 ` Mel Gorman
2016-07-06 0:15 ` Minchan Kim
2016-07-01 20:01 ` [PATCH 02/31] mm, vmscan: move lru_lock to the node Mel Gorman
2016-07-05 0:03 ` Minchan Kim
2016-07-01 20:01 ` [PATCH 03/31] mm, vmscan: move LRU lists to node Mel Gorman
2016-07-05 1:19 ` Minchan Kim
2016-07-05 10:14 ` Mel Gorman
2016-07-01 20:01 ` [PATCH 04/31] mm, vmscan: begin reclaiming pages on a per-node basis Mel Gorman
2016-07-07 1:12 ` Joonsoo Kim
2016-07-07 9:48 ` Mel Gorman
2016-07-08 2:28 ` Joonsoo Kim
2016-07-08 10:05 ` Mel Gorman
2016-07-14 6:28 ` Joonsoo Kim
2016-07-14 7:48 ` Vlastimil Babka
2016-07-18 4:52 ` Joonsoo Kim
2016-07-18 12:11 ` Mel Gorman
2016-07-18 14:27 ` Mel Gorman
2016-07-19 8:30 ` Joonsoo Kim
2016-07-19 14:25 ` Mel Gorman
2016-07-01 20:01 ` [PATCH 05/31] mm, vmscan: have kswapd only scan based on the highest requested zone Mel Gorman
2016-07-01 20:01 ` [PATCH 06/31] mm, vmscan: make kswapd reclaim in terms of nodes Mel Gorman
2016-07-01 20:01 ` [PATCH 07/31] mm, vmscan: remove balance gap Mel Gorman
2016-07-01 20:01 ` [PATCH 08/31] mm, vmscan: simplify the logic deciding whether kswapd sleeps Mel Gorman
2016-07-05 5:59 ` Minchan Kim
2016-07-05 10:26 ` Mel Gorman
2016-07-06 0:30 ` Minchan Kim
2016-07-06 8:31 ` Mel Gorman
2016-07-07 5:51 ` Minchan Kim
2016-07-07 9:56 ` Mel Gorman
2016-07-07 1:20 ` Joonsoo Kim
2016-07-07 10:17 ` Mel Gorman
2016-07-08 2:44 ` Joonsoo Kim
2016-07-08 10:11 ` Mel Gorman
2016-07-14 5:23 ` Joonsoo Kim
2016-07-14 8:32 ` Vlastimil Babka
2016-07-18 5:07 ` Joonsoo Kim
2016-07-18 6:51 ` Vlastimil Babka
2016-07-18 7:24 ` Joonsoo Kim
2016-07-14 9:05 ` Mel Gorman
2016-07-18 5:03 ` Joonsoo Kim
2016-07-01 20:01 ` [PATCH 09/31] mm, vmscan: by default have direct reclaim only shrink once per node Mel Gorman
2016-07-07 1:43 ` Joonsoo Kim
2016-07-07 10:27 ` Mel Gorman
2016-07-01 20:01 ` [PATCH 10/31] mm, vmscan: remove duplicate logic clearing node congestion and dirty state Mel Gorman
2016-07-01 20:01 ` [PATCH 11/31] mm: vmscan: do not reclaim from kswapd if there is any eligible zone Mel Gorman
2016-07-05 6:11 ` Minchan Kim
2016-07-05 10:38 ` Mel Gorman
2016-07-06 1:25 ` Minchan Kim
2016-07-06 8:42 ` Mel Gorman
2016-07-07 6:27 ` Minchan Kim
2016-07-07 10:55 ` Mel Gorman
2016-07-01 20:01 ` [PATCH 12/31] mm, vmscan: make shrink_node decisions more node-centric Mel Gorman
2016-07-05 6:24 ` Minchan Kim
2016-07-05 10:40 ` Mel Gorman
2016-07-01 20:01 ` [PATCH 13/31] mm, memcg: move memcg limit enforcement from zones to nodes Mel Gorman
2016-07-01 20:01 ` [PATCH 14/31] mm, workingset: make working set detection node-aware Mel Gorman
2016-07-01 20:01 ` [PATCH 15/31] mm, page_alloc: consider dirtyable memory in terms of nodes Mel Gorman
2016-07-01 20:01 ` [PATCH 16/31] mm: move page mapped accounting to the node Mel Gorman
2016-07-01 20:01 ` [PATCH 17/31] mm: rename NR_ANON_PAGES to NR_ANON_MAPPED Mel Gorman
2016-07-01 20:01 ` [PATCH 18/31] mm: move most file-based accounting to the node Mel Gorman
2016-07-01 20:01 ` [PATCH 19/31] mm: move vmscan writes and file write " Mel Gorman
2016-07-01 20:01 ` [PATCH 20/31] mm, vmscan: only wakeup kswapd once per node for the requested classzone Mel Gorman
2016-07-07 1:24 ` Joonsoo Kim
2016-07-07 10:58 ` Mel Gorman
2016-07-01 20:01 ` [PATCH 21/31] mm, page_alloc: Wake kswapd based on the highest eligible zone Mel Gorman
2016-07-01 20:01 ` [PATCH 22/31] mm: convert zone_reclaim to node_reclaim Mel Gorman
2016-07-01 20:01 ` [PATCH 23/31] mm, vmscan: Avoid passing in classzone_idx unnecessarily to shrink_node Mel Gorman
2016-07-01 20:01 ` [PATCH 24/31] mm, vmscan: Avoid passing in classzone_idx unnecessarily to compaction_ready Mel Gorman
2016-07-01 20:01 ` [PATCH 25/31] mm, vmscan: add classzone information to tracepoints Mel Gorman
2016-07-01 20:01 ` [PATCH 26/31] mm, page_alloc: remove fair zone allocation policy Mel Gorman
2016-07-01 20:01 ` [PATCH 27/31] mm: page_alloc: cache the last node whose dirty limit is reached Mel Gorman
2016-07-01 20:01 ` [PATCH 28/31] mm: vmstat: replace __count_zone_vm_events with a zone id equivalent Mel Gorman
2016-07-01 20:01 ` [PATCH 29/31] mm: vmstat: account per-zone stalls and pages skipped during reclaim Mel Gorman
2016-07-01 20:01 ` [PATCH 30/31] mm, vmstat: print node-based stats in zoneinfo file Mel Gorman
2016-07-01 20:01 ` [PATCH 31/31] mm, vmstat: Remove zone and node double accounting by approximating retries Mel Gorman
2016-07-06 0:02 ` Minchan Kim
2016-07-06 8:58 ` Mel Gorman
2016-07-06 9:33 ` Mel Gorman
2016-07-07 6:47 ` Minchan Kim
2016-07-06 18:12 ` Dave Hansen
2016-07-07 11:26 ` Mel Gorman
2016-07-04 1:37 ` [PATCH 00/31] Move LRU page reclaim from zones to nodes v8 Minchan Kim
2016-07-04 4:34 ` Mel Gorman [this message]
2016-07-04 8:04 ` Minchan Kim
2016-07-04 9:55 ` Mel Gorman
2016-07-06 1:51 ` Minchan Kim
-- strict thread matches above, loose matches on Subject: below --
2016-07-01 15:37 Mel Gorman
2016-07-07 23:27 ` Dave Chinner
2016-07-08 9:52 ` Mel Gorman
2016-07-11 0:47 ` Dave Chinner
2016-07-11 9:02 ` Mel Gorman
2016-07-12 2:52 ` Dave Chinner
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=20160704043405.GB11498@techsingularity.net \
--to=mgorman@techsingularity.net \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).