From: Linus Torvalds <torvalds@linux-foundation.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Matthew Wilcox <matthew@wil.cx>,
Andrew Morton <akpm@linux-foundation.org>,
"J. Bruce Fields" <bfields@citi.umich.edu>,
"Zhang, Yanmin" <yanmin_zhang@linux.intel.com>,
LKML <linux-kernel@vger.kernel.org>,
Alexander Viro <viro@ftp.linux.org.uk>,
linux-fsdevel@vger.kernel.org
Subject: Re: AIM7 40% regression with 2.6.26-rc1
Date: Wed, 7 May 2008 10:47:20 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.1.10.0805071032280.3024@woody.linux-foundation.org> (raw)
In-Reply-To: <alpine.LFD.1.10.0805071028400.3024@woody.linux-foundation.org>
On Wed, 7 May 2008, Linus Torvalds wrote:
>
> All the "normal" mutex code use fine-grained locking, so even if you slow
> down the fast path, that won't cause the same kind of fastpath->slowpath
> increase.
Put another way: let's say that the "good fastpath" is basically a single
locked instruction - ~12 cycles on AMD, ~35 Core 2. That's the
no-bouncing, no-contention case.
Doing it with debugging (call overhead, spinlocks, local irq saving rtc)
will probably easily triple it or more, but we're not changing anything
else. There's no "downstream" effect: the behaviour itself doesn't change.
It doesn't get more bouncing, it doesn't start sleeping.
But what happens if the lock has the *potential* for conflicts is
different.
There, a "longish pause + fast lock + short average code sequece + fast
unlock" is quite likely to stay uncontended for a fair amount of time, and
while it will be much slower than the no-contention-at-all case (because
you do get a pretty likely cacheline event at the "fast lock" part), with
a fairly low number of CPU's and a long enough pause, you *also* easily
get into a pattern where the thing that got the lock will likely also get
to unlock without dropping the cacheline.
So far so good.
But that basically depends on the fact that "lock + work + unlock" is
_much_ shorter than the "longish pause" in between, so that even if you
have <n> CPU's all doing the same thing, their pauses between the locked
section are still bigger than <n> times that short time.
Once that is no longer true, you now start to bounce both at the lock
*and* the unlock, and now that whole sequence got likely ten times slower.
*AND* because it now actually has real contention, it actually got even
worse: if the lock is a sleeping one, you get *another* order of magnitude
just because you now started doing scheduling overhead too!
So the thing is, it just breaks down very badly. A spinlock that gets
contention probably gets ten times slower due to bouncing the cacheline. A
semaphore that gets contention probably gets a *hundred* times slower, or
more.
And so my bet is that both the old and the new semaphores had the same bad
break-down situation, but the new semaphores just are a lot easier to
trigger it because they are at least three times costlier than the old
ones, so you just hit the bad behaviour with much lower loads (or fewer
number of CPU's).
But spinlocks really do behave much better when contended, because at
least they don't get the even bigger hit of also hitting the scheduler. So
the old semaphores would have behaved badly too *eventually*, they just
needed a more extreme case to show that bad behavior.
Linus
next prev parent reply other threads:[~2008-05-07 17:47 UTC|newest]
Thread overview: 140+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-06 5:48 AIM7 40% regression with 2.6.26-rc1 Zhang, Yanmin
2008-05-06 11:18 ` Matthew Wilcox
2008-05-06 11:44 ` Ingo Molnar
2008-05-06 12:09 ` Matthew Wilcox
2008-05-06 16:23 ` Matthew Wilcox
2008-05-06 16:36 ` Linus Torvalds
2008-05-06 16:42 ` Matthew Wilcox
2008-05-06 16:39 ` Alan Cox
2008-05-06 16:51 ` Matthew Wilcox
2008-05-06 16:45 ` Alan Cox
2008-05-06 17:42 ` Linus Torvalds
2008-05-06 20:28 ` Linus Torvalds
2008-05-06 16:44 ` J. Bruce Fields
2008-05-06 17:21 ` Andrew Morton
2008-05-06 17:31 ` Matthew Wilcox
2008-05-06 17:49 ` Ingo Molnar
2008-05-06 18:07 ` Andrew Morton
2008-05-11 11:11 ` Matthew Wilcox
2008-05-06 17:39 ` Ingo Molnar
2008-05-07 6:49 ` Zhang, Yanmin
2008-05-06 17:45 ` Linus Torvalds
2008-05-07 16:38 ` Matthew Wilcox
2008-05-07 16:55 ` Linus Torvalds
2008-05-07 17:08 ` Linus Torvalds
2008-05-07 17:16 ` Andrew Morton
2008-05-07 17:27 ` Linus Torvalds
2008-05-07 17:22 ` Ingo Molnar
2008-05-07 17:25 ` Ingo Molnar
2008-05-07 17:31 ` Linus Torvalds
2008-05-07 17:47 ` Linus Torvalds [this message]
2008-05-07 17:49 ` Ingo Molnar
2008-05-07 18:02 ` Linus Torvalds
2008-05-07 18:17 ` Ingo Molnar
2008-05-07 18:27 ` Linus Torvalds
2008-05-07 18:43 ` Ingo Molnar
2008-05-07 19:01 ` Linus Torvalds
2008-05-07 19:09 ` Ingo Molnar
2008-05-07 19:24 ` Matthew Wilcox
2008-05-07 19:44 ` Linus Torvalds
2008-05-07 20:00 ` Oi. NFS people. Read this Matthew Wilcox
2008-05-07 22:10 ` Trond Myklebust
2008-05-09 1:43 ` J. Bruce Fields
2008-05-08 3:24 ` AIM7 40% regression with 2.6.26-rc1 Zhang, Yanmin
2008-05-08 3:34 ` Linus Torvalds
2008-05-08 4:37 ` Zhang, Yanmin
2008-05-08 14:58 ` Linus Torvalds
2008-05-07 2:11 ` Zhang, Yanmin
2008-05-07 3:41 ` Zhang, Yanmin
2008-05-07 3:59 ` Andrew Morton
2008-05-07 4:46 ` Zhang, Yanmin
2008-05-07 6:26 ` Ingo Molnar
2008-05-07 6:28 ` Ingo Molnar
2008-05-07 7:05 ` Zhang, Yanmin
2008-05-07 11:00 ` Andi Kleen
2008-05-07 11:46 ` Matthew Wilcox
2008-05-07 12:21 ` Andi Kleen
2008-05-07 14:36 ` Linus Torvalds
2008-05-07 14:35 ` Alan Cox
2008-05-07 15:00 ` Linus Torvalds
2008-05-07 15:02 ` Linus Torvalds
2008-05-07 14:57 ` Andi Kleen
2008-05-07 15:31 ` Andrew Morton
2008-05-07 16:22 ` Matthew Wilcox
2008-05-07 15:19 ` Linus Torvalds
2008-05-07 17:14 ` Ingo Molnar
2008-05-08 2:44 ` Zhang, Yanmin
2008-05-08 3:29 ` Linus Torvalds
2008-05-08 4:08 ` Zhang, Yanmin
2008-05-08 4:17 ` Linus Torvalds
2008-05-08 12:01 ` [patch] speed up / fix the new generic semaphore code (fix AIM7 40% regression with 2.6.26-rc1) Ingo Molnar
2008-05-08 12:28 ` Ingo Molnar
2008-05-08 14:43 ` Ingo Molnar
2008-05-08 15:10 ` [git pull] scheduler fixes Ingo Molnar
2008-05-08 15:33 ` Adrian Bunk
2008-05-08 15:41 ` Ingo Molnar
2008-05-08 19:42 ` Adrian Bunk
2008-05-11 11:03 ` Matthew Wilcox
2008-05-11 11:14 ` Matthew Wilcox
2008-05-11 11:48 ` Matthew Wilcox
2008-05-11 12:50 ` Ingo Molnar
2008-05-11 12:52 ` Ingo Molnar
2008-05-11 13:02 ` Matthew Wilcox
2008-05-11 13:26 ` Matthew Wilcox
2008-05-11 14:00 ` Ingo Molnar
2008-05-11 14:18 ` Matthew Wilcox
2008-05-11 14:42 ` Ingo Molnar
2008-05-11 14:48 ` Matthew Wilcox
2008-05-11 15:19 ` Ingo Molnar
2008-05-11 15:29 ` Matthew Wilcox
2008-05-13 14:11 ` Ingo Molnar
2008-05-13 14:21 ` Matthew Wilcox
2008-05-13 14:42 ` Ingo Molnar
2008-05-13 15:28 ` Matthew Wilcox
2008-05-13 17:13 ` Ingo Molnar
2008-05-13 17:22 ` Linus Torvalds
2008-05-13 21:05 ` Ingo Molnar
2008-05-11 13:54 ` Ingo Molnar
2008-05-11 14:22 ` Matthew Wilcox
2008-05-11 14:32 ` Ingo Molnar
2008-05-11 14:46 ` Matthew Wilcox
2008-05-11 16:47 ` Linus Torvalds
2008-05-11 13:01 ` Ingo Molnar
2008-05-11 13:06 ` Matthew Wilcox
2008-05-11 13:45 ` Ingo Molnar
2008-05-11 14:10 ` Sven Wegener
2008-05-08 16:02 ` [patch] speed up / fix the new generic semaphore code (fix AIM7 40% regression with 2.6.26-rc1) Linus Torvalds
2008-05-08 18:30 ` Linus Torvalds
2008-05-08 20:19 ` Ingo Molnar
2008-05-08 20:27 ` Linus Torvalds
2008-05-08 21:45 ` Ingo Molnar
2008-05-08 22:02 ` Ingo Molnar
2008-05-08 22:55 ` Linus Torvalds
2008-05-08 23:07 ` Linus Torvalds
2008-05-08 23:14 ` Linus Torvalds
2008-05-08 23:16 ` Alan Cox
2008-05-08 23:33 ` Linus Torvalds
2008-05-08 23:27 ` Alan Cox
2008-05-09 6:50 ` Ingo Molnar
2008-05-09 8:29 ` Andi Kleen
2008-05-08 13:20 ` Matthew Wilcox
2008-05-08 15:01 ` Ingo Molnar
2008-05-08 13:56 ` Arjan van de Ven
2008-05-08 6:43 ` AIM7 40% regression with 2.6.26-rc1 Ingo Molnar
2008-05-08 6:48 ` Andrew Morton
2008-05-08 7:14 ` Zhang, Yanmin
2008-05-08 7:39 ` Ingo Molnar
2008-05-08 8:44 ` Zhang, Yanmin
2008-05-08 9:21 ` Ingo Molnar
2008-05-08 9:29 ` Ingo Molnar
2008-05-08 9:30 ` Zhang, Yanmin
2008-05-07 16:20 ` Ingo Molnar
2008-05-07 16:35 ` Linus Torvalds
2008-05-07 17:05 ` Ingo Molnar
2008-05-07 17:24 ` Linus Torvalds
2008-05-07 17:36 ` Ingo Molnar
2008-05-07 17:55 ` Linus Torvalds
2008-05-07 17:59 ` Matthew Wilcox
2008-05-07 18:17 ` Linus Torvalds
2008-05-07 18:49 ` Ingo Molnar
2008-05-07 13:59 ` Alan Cox
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=alpine.LFD.1.10.0805071032280.3024@woody.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=bfields@citi.umich.edu \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=mingo@elte.hu \
--cc=viro@ftp.linux.org.uk \
--cc=yanmin_zhang@linux.intel.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).