From: Mel Gorman <mgorman@suse.de>
To: Nathan Zimmer <nzimmer@sgi.com>
Cc: holt@sgi.com, linux-mm@kvack.org
Subject: Re: Improving lock pages
Date: Wed, 6 Feb 2013 16:31:29 +0000 [thread overview]
Message-ID: <20130206163129.GR21389@suse.de> (raw)
In-Reply-To: <20130115173814.GA13329@gulag1.americas.sgi.com>
On Tue, Jan 15, 2013 at 11:38:14AM -0600, Nathan Zimmer wrote:
>
> Hello Mel,
Hi Nathan,
> You helped some time ago with contention in lock_pages on very large boxes.
It was Nick Piggin and Jack Steiner that helped the situation within SLES
and before my time. I inherited the relevant patches but made relatively
few contributions to the effort.
> You worked with Jack Steiner on this. Currently I am tasked with improving this
> area even more. So I am fishing for any more ideas that would be productive or
> worth trying.
>
> I have some numbers from a 512 machine.
>
> Linux uvpsw1 3.0.51-0.7.9-default #1 SMP Thu Nov 29 22:12:17 UTC 2012 (f3be9d0) x86_64 x86_64 x86_64 GNU/Linux
> 0.166850
> 0.082339
> 0.248428
> 0.081197
> 0.127635
Ok, this looks like a SLES 11 SP2 kernel and so includes some unlock/lock
page optimisations.
> Linux uvpsw1 3.8.0-rc1-medusa_ntz_clean-dirty #32 SMP Tue Jan 8 16:01:04 CST 2013 x86_64 x86_64 x86_64 GNU/Linux
> 0.151778
> 0.118343
> 0.135750
> 0.437019
> 0.120536
>
And this is a mainline-ish kernel which doesn't.
The main reason I never made an strong effort to push them upstream
because the problems are barely observable on any machine I had access to.
The unlock page optimisation requires a page flag and while it helps
profiles a little, the effects are barely observable on smaller machines
(at least since I last checked). One machine it was reported to help
dramatically was a 768-way 128 node machine.
Forthe 512-way machine you're testing with the figures are marginal. The
time to exit is shorter but the amount of time is tiny and very close to
noise. I forward ported the relevant patches but on a 48-way machine the
results for the same test were well within the noise and the standard
deviation was higher.
I know you're tasked with improving this area more but what are you
using as your example workload? What's the minimum sized machine needed
for the optimisations to make a difference?
--
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:[~2013-02-06 16:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-15 17:38 Improving lock pages Nathan Zimmer
2013-01-15 18:10 ` Nathan Zimmer
2013-02-06 16:31 ` Mel Gorman [this message]
2013-02-08 21:55 ` Nathan Zimmer
2013-02-13 10:47 ` 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=20130206163129.GR21389@suse.de \
--to=mgorman@suse.de \
--cc=holt@sgi.com \
--cc=linux-mm@kvack.org \
--cc=nzimmer@sgi.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;
as well as URLs for NNTP newsgroup(s).