From: Michal Hocko <mhocko@suse.cz>
To: linux-mm@kvack.org
Cc: Ying Han <yinghan@google.com>,
Johannes Weiner <hannes@cmpxchg.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Rik van Riel <riel@redhat.com>, Hugh Dickins <hughd@google.com>,
Mel Gorman <mgorman@suse.de>,
Glauber Costa <glommer@parallels.com>
Subject: Re: [RFC 0/3] soft reclaim rework
Date: Thu, 11 Apr 2013 10:43:46 +0200 [thread overview]
Message-ID: <20130411084346.GB1488@dhcp22.suse.cz> (raw)
In-Reply-To: <1365509595-665-1-git-send-email-mhocko@suse.cz>
Hi,
I have retested kbuild test on a bare HW (8CPUs, 1GB RAM limited by
mem=1G, 2GB swap partition). There are 2 groups (A, B) without any hard
limit and group A has soft limit set to 700M (to have 70% of available
memory). Build starts after fresh boot by extracting sources and
make -j4 vmlinux.
Each group works on a separate source tree. I have repeated the test 3
times:
First some data as returned by /usr/bin/time -v:
* Patched:
A:
User time (seconds): 1133.06
User time (seconds): 1132.84
User time (seconds): 1135.37
Avg: 1133.76
System time (seconds): 258.02
System time (seconds): 259.33
System time (seconds): 258.83
Avg: 258.73
Elapsed (wall clock) time (h:mm:ss or m:ss): 8:57.55
Elapsed (wall clock) time (h:mm:ss or m:ss): 8:55.68
Elapsed (wall clock) time (h:mm:ss or m:ss): 8:50.96
Avg: 08:54.73
B:
User time (seconds): 1149.22
User time (seconds): 1153.98
User time (seconds): 1150.37
Avg: 1151.19 (101.5% of A)
System time (seconds): 262.13
System time (seconds): 263.31
System time (seconds): 260.84
Avg: 262.09 (101.3% of A)
Elapsed (wall clock) time (h:mm:ss or m:ss): 10:13.37
Elapsed (wall clock) time (h:mm:ss or m:ss): 10:17.15
Elapsed (wall clock) time (h:mm:ss or m:ss): 10:05.23
Avg: 10:11.92 (114.4% of A)
* Base:
A:
User time (seconds): 1132.58
User time (seconds): 1140.63
User time (seconds): 1135.68
avg: 1136.30 (100.2% of A - patched)
System time (seconds): 264.88
System time (seconds): 263.54
System time (seconds): 261.99
avg: 263.47 (101.8 of A - patched)
Elapsed (wall clock) time (h:mm:ss or m:ss): 9:48.54
Elapsed (wall clock) time (h:mm:ss or m:ss): 9:50.44
Elapsed (wall clock) time (h:mm:ss or m:ss): 9:44.28
avg: 09:47.75 (109.9% of A - patched)
B:
User time (seconds): 1138.32
User time (seconds): 1135.70
User time (seconds): 1136.80
avg: 1136.94 (100.2% of A - patched)
System time (seconds): 261.56
System time (seconds): 262.10
System time (seconds): 262.24
avg: 261.97 (100% of A - patched)
Elapsed (wall clock) time (h:mm:ss or m:ss): 9:39.17
Elapsed (wall clock) time (h:mm:ss or m:ss): 9:46.95
Elapsed (wall clock) time (h:mm:ss or m:ss): 9:44.73
avg: 09:47.75 (109.1% of A - patched)
While for the patched kernel soft limit helped to protect A's working
set so it was faster (14% in the total time) than B without any limits.
The unpatched kernel has treated them more or less equally regardless
the softlimit setting.
If we compare patched and base kernels numbers then the overall
situation improved slightly (A+B Elapsed time is 2% smaller) with the
patched kernel which was quite surprising for me. Maybe a side effect of
priority-0 soft reclaim in the base kernel.
As the variance between runs wasn't very high I have focused on the first
run for the memory usage and reclaim statistics comparisons between the
base and patched kernels.
* Patched:
pgscan_direct_dma32 252408
pgscan_kswapd_dma32 988928
pgsteal_direct_dma32 63565
pgsteal_kswapd_dma32 905223
* Base:
pgscan_direct_dma32 97310 (38% of patched)
pgscan_kswapd_dma32 1702971 (172%)
pgsteal_direct_dma32 83377 (131%)
pgsteal_kswapd_dma32 1534616 (169.5%)
So it seems that we scanned much more on the patched kernel during the
direct reclaim but we have reclaimed less nevertheless. This is most
probably because there is a bigger pressure on B's LRU and we encounter
more dirty pages so more pages are scanned in the end. In sum we scanned
and reclaimed less (by 45% resp. 67%) though.
You can find some graphs at:
- http://labs.suse.cz/mhocko/soft_limit_rework/base-usage.png
- http://labs.suse.cz/mhocko/soft_limit_rework/patched-usage.png
Per group charges over time.
- http://labs.suse.cz/mhocko/soft_limit_rework/base-usage-histogram.png
- http://labs.suse.cz/mhocko/soft_limit_rework/patched-usage-histogram.png
Same here but in the histogram form to see the main tendencies.
- http://labs.suse.cz/mhocko/soft_limit_rework/pgscan.png
- http://labs.suse.cz/mhocko/soft_limit_rework/pgsteal.png
Scanning and reclaiming activity comparision between the base and the
patched kernel.
--
Michal Hocko
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:[~2013-04-11 8:43 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-09 12:13 Michal Hocko
2013-04-09 12:13 ` [RFC 1/3] memcg: integrate soft reclaim tighter with zone shrinking code Michal Hocko
2013-04-09 13:08 ` Johannes Weiner
2013-04-09 13:31 ` Michal Hocko
2013-04-09 13:57 ` Glauber Costa
2013-04-09 14:22 ` Michal Hocko
2013-04-09 16:45 ` Kamezawa Hiroyuki
2013-04-09 17:05 ` Michal Hocko
2013-04-14 0:42 ` Mel Gorman
2013-04-14 14:34 ` Michal Hocko
2013-04-14 14:55 ` Johannes Weiner
2013-04-14 15:04 ` Michal Hocko
2013-04-14 15:11 ` Michal Hocko
2013-04-14 18:03 ` Rik van Riel
2013-04-09 12:13 ` [RFC 2/3] memcg: Ignore soft limit until it is explicitly specified Michal Hocko
2013-04-09 13:24 ` Johannes Weiner
2013-04-09 13:42 ` Michal Hocko
2013-04-09 17:10 ` Kamezawa Hiroyuki
2013-04-09 17:22 ` Michal Hocko
2013-04-09 12:13 ` [RFC 3/3] vmscan, memcg: Do softlimit reclaim also for targeted reclaim Michal Hocko
2013-04-22 2:14 ` Michal Hocko
2013-04-09 15:37 ` [RFC 0/3] soft reclaim rework Michal Hocko
2013-04-09 15:50 ` Michal Hocko
2013-04-11 8:43 ` Michal Hocko [this message]
2013-04-11 9:07 ` Michal Hocko
2013-04-11 13:04 ` Michal Hocko
2013-04-17 22:52 ` Ying Han
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=20130411084346.GB1488@dhcp22.suse.cz \
--to=mhocko@suse.cz \
--cc=glommer@parallels.com \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=riel@redhat.com \
--cc=yinghan@google.com \
/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