From: Christoph Lameter <clameter@engr.sgi.com>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Andrew Morton <akpm@osdl.org>, Hugh Dickins <hugh@veritas.com>,
Nick Piggin <piggin@cyberone.com.au>,
linux-mm@kvack.org
Subject: Re: pagefault scalability patches
Date: Wed, 17 Aug 2005 16:12:05 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.62.0508171603240.19363@schroedinger.engr.sgi.com> (raw)
In-Reply-To: <Pine.LNX.4.58.0508171559350.3553@g5.osdl.org>
On Wed, 17 Aug 2005, Linus Torvalds wrote:
> On Wed, 17 Aug 2005, Christoph Lameter wrote:
> >
> > We are trading 2x (spinlock(page_table_lock),
> > spin_unlock(page_table_lock)) against one atomic inc.
>
> Bzzt. Thank you for playing.
>
> Spinunlock is free on x86 and x86-64, since it's a plain normal store. The
> x86 memory ordering semantics take care of the rest.
The same is basically true for ia64 (there is an additional memory barrier
since ordering must be enforced at that point)
> In other words, one uncontended spinlock/unlock pair is pretty much
> _exactly_ the same cost as one single atomic operation, and there is no
> win.
We have no problems if the lock are not contended. Then we just reduce the
overhead by eliminating one semaphore instruction.
If they are contended then spinlock/unlock serializes the page
fault handler.
Numbers:
Unpatched:
Gb Rep Threads User System Wall flt/cpu/s fault/wsec
16 3 1 0.757s 62.772s 63.052s 49515.393 49522.112
16 3 2 0.674s 68.268s 36.048s 45627.693 86230.400
16 3 4 0.649s 66.478s 20.061s 46861.663 152603.033
16 3 8 0.666s 179.611s 25.096s 17449.372 121159.869
16 3 16 0.721s 545.957s 38.015s 5754.251 82456.599
16 3 32 1.327s 1718.947s 59.083s 1828.620 52573.584
16 3 64 3.181s 5260.674s 93.047s 597.609 33651.618
16 3 128 15.966s 19392.742s 163.090s 162.078 19192.626
16 3 256 18.214s 9994.286s 84.077s 314.180 37105.725
16 3 512 13.866s 5023.788s 42.063s 624.443 73776.955
Page fault patches
Gb Rep Threads User System Wall flt/cpu/s fault/wsec
4 3 1 0.153s 12.314s 12.047s 63077.153 63065.474
4 3 2 0.155s 10.430s 5.074s 74290.224 136812.728
4 3 4 0.157s 9.377s 2.095s 82477.064 266154.766
4 3 8 0.164s 10.348s 2.002s 74807.804 388714.846
4 3 16 0.250s 20.687s 2.017s 37560.913 360858.481
4 3 32 0.568s 43.941s 2.034s 17668.743 335334.362
4 3 64 2.954s 95.528s 2.066s 7985.502 294723.687
4 3 128 15.449s 259.534s 3.053s 2859.924 222310.352
4 3 256 16.108s 137.784s 2.019s 5110.263 357984.896
4 3 512 14.083s 82.377s 1.049s 8152.851 527180.088
--
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:[~2005-08-17 23:12 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-17 22:17 Andrew Morton
2005-08-17 22:19 ` Christoph Lameter
2005-08-17 22:36 ` Linus Torvalds
2005-08-17 22:51 ` Christoph Lameter
2005-08-17 23:01 ` Linus Torvalds
2005-08-17 23:12 ` Christoph Lameter [this message]
2005-08-17 23:23 ` Linus Torvalds
2005-08-17 23:31 ` Christoph Lameter
2005-08-17 23:30 ` Andrew Morton
2005-08-17 23:33 ` Christoph Lameter
2005-08-17 23:44 ` Andrew Morton
2005-08-17 23:52 ` Peter Chubb
2005-08-17 23:58 ` Christoph Lameter
2005-08-18 0:47 ` Andrew Morton
2005-08-18 16:09 ` Christoph Lameter
2005-08-22 2:13 ` Benjamin Herrenschmidt
2005-08-18 0:43 ` Andrew Morton
2005-08-18 16:04 ` Christoph Lameter
2005-08-18 20:16 ` Hugh Dickins
2005-08-19 1:22 ` [PATCH] use mm_counter macros for nr_pte since its also under ptl Christoph Lameter
2005-08-19 3:17 ` Andrew Morton
2005-08-19 3:51 ` Christoph Lameter
2005-08-19 1:33 ` pagefault scalability patches Christoph Lameter
2005-08-19 3:53 ` [RFC] Concept for delayed counter updates in mm_struct Christoph Lameter
2005-08-19 4:29 ` Andrew Morton
2005-08-19 4:34 ` Andi Kleen
2005-08-19 4:49 ` Linus Torvalds
2005-08-19 16:06 ` Christoph Lameter
2005-08-20 7:33 ` [PATCH] mm_struct counter deltas in task_struct Christoph Lameter
2005-08-20 7:35 ` [PATCH] Use deltas to replace atomic inc Christoph Lameter
2005-08-20 7:58 ` Andrew Morton
2005-08-22 3:32 ` Christoph Lameter
2005-08-22 3:48 ` Linus Torvalds
2005-08-22 4:06 ` Christoph Lameter
2005-08-22 4:18 ` Linus Torvalds
2005-08-22 13:23 ` Christoph Lameter
2005-08-22 14:22 ` Hugh Dickins
2005-08-22 15:24 ` Christoph Lameter
2005-08-22 15:43 ` Andi Kleen
2005-08-22 16:24 ` Christoph Lameter
2005-08-22 20:30 ` [PATCH] mm_struct counter deltas V2 Christoph Lameter
2005-08-22 20:31 ` [PATCH] Use deltas to replace atomic inc V2 Christoph Lameter
2005-08-22 2:09 ` pagefault scalability patches Benjamin Herrenschmidt
2005-08-18 2:00 ` Nick Piggin
2005-08-18 8:38 ` Nick Piggin
2005-08-18 16:17 ` Christoph Lameter
2005-08-22 2:04 ` Benjamin Herrenschmidt
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=Pine.LNX.4.62.0508171603240.19363@schroedinger.engr.sgi.com \
--to=clameter@engr.sgi.com \
--cc=akpm@osdl.org \
--cc=hugh@veritas.com \
--cc=linux-mm@kvack.org \
--cc=piggin@cyberone.com.au \
--cc=torvalds@osdl.org \
/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