From: Linus Torvalds <torvalds@osdl.org>
To: Zwane Mwaikambo <zwane@fsmlabs.com>
Cc: Paul Mackerras <paulus@samba.org>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@osdl.org>, Anton Blanchard <anton@samba.org>,
"Nakajima, Jun" <jun.nakajima@intel.com>, Andi Kleen <ak@suse.de>,
Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH] Yielding processor resources during lock contention
Date: Sat, 11 Sep 2004 22:10:21 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.58.0409112200060.13491@ppc970.osdl.org> (raw)
In-Reply-To: <Pine.LNX.4.53.0409120009510.2297@montezuma.fsmlabs.com>
On Sun, 12 Sep 2004, Zwane Mwaikambo wrote:
>
> On i386 processors with PNI this is achieved by using the
> monitor/mwait opcodes to halt the processor until a write to the lock is
> done.
I'd seriously suggest you ask Intel for an official opinion on this. Last
I heard (and that was, I believe, before monitor/mwait had been officially
announced, so it's certainly a bit dated now) it wasn't architecturally
clear that it's a good idea using it for things like spinlocks.
In particular, if the CPU idly waits for a cacheline to be dirtied, it is
entirely possible that the other CPU that owns the lock and releases it
won't actually _tell_ the world that the lock has been released for quite
some time. After all, why should it - if it is the exclusive owner, and it
sees no memory traffic on the bus, it may have no reason to push out the
fact that it just released the lock. Just keep it dirty in its caches.
In other words: monitor/mwait on purpose obviously causes fewer bus
cycles. But that very fact may well mean (at least in theory) that you get
very high latencies. It could make spinlock contention very very unfair
(the original CPU keeps getting the lock over and over again, while the
monitor/mwait one never gets to play), and it might also make ping-pong
locking latency be extremely high.
Also, it's entirely possible that monitor/mwait ends up shutting down the
CPU to the point that getting out of a lower-power mode might have a
latency of microseconds or even milliseconds. External (or even internal)
voltage regulators and frequency changes are not instantaneous by any
means..
In other words, I would strongly suggest you _not_ really consider this a
serious thing (feel free to play around with it and try to get some
numbers) with this without getting an answer from Intel about what the
_architected_ behaviour of monitor/mwait is, from a latency standpoint.
Because otherwise you might find that even if it performs like you want it
to on some existing machine, next year it would suck so badly that it's
not even funny.
Linus
next prev parent reply other threads:[~2004-09-12 5:11 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-03 0:02 [PATCH][5/8] Arch agnostic completely out of line locks / ppc64 Zwane Mwaikambo
2004-09-09 5:42 ` Paul Mackerras
2004-09-09 12:41 ` Zwane Mwaikambo
2004-09-09 14:54 ` Linus Torvalds
2004-09-09 14:55 ` Linus Torvalds
2004-09-09 15:32 ` Zwane Mwaikambo
2004-09-12 4:59 ` [PATCH] Yielding processor resources during lock contention Zwane Mwaikambo
2004-09-12 5:00 ` Andrew Morton
2004-09-12 5:10 ` Anton Blanchard
2004-09-12 5:13 ` Zwane Mwaikambo
2004-09-12 4:32 ` Nick Piggin
2004-09-12 5:33 ` Zwane Mwaikambo
2004-09-12 4:46 ` Nick Piggin
2004-09-12 5:51 ` Zwane Mwaikambo
2004-09-12 5:02 ` Nick Piggin
2004-09-12 6:09 ` Anton Blanchard
2004-09-12 6:58 ` William Lee Irwin III
2004-09-12 5:18 ` Andrew Morton
2004-09-12 5:10 ` Linus Torvalds [this message]
2004-09-12 5:27 ` Zwane Mwaikambo
2004-09-13 12:21 ` [PATCH] Yielding processor resources during lock contention #2 Zwane Mwaikambo
2004-09-12 7:49 ` [PATCH] Yielding processor resources during lock contention Ingo Molnar
2004-09-12 16:10 ` Zwane Mwaikambo
2004-09-12 19:34 ` Ingo Molnar
2004-09-12 10:10 ` Arnd Bergmann
2004-09-12 10:43 ` Anton Blanchard
2004-09-12 11:12 ` Arnd Bergmann
2004-09-09 15:43 ` [PATCH][5/8] Arch agnostic completely out of line locks / ppc64 Anton Blanchard
2004-09-09 17:19 ` William Lee Irwin III
2004-09-09 21:38 ` Paul Mackerras
2004-09-09 22:00 ` William Lee Irwin III
2004-09-09 23:36 ` Paul Mackerras
2004-09-10 0:09 ` William Lee Irwin III
2004-09-10 0:21 ` Linus Torvalds
2004-09-10 0:35 ` Anton Blanchard
2004-09-10 0:54 ` Linus Torvalds
2004-09-10 1:42 ` Anton Blanchard
2004-09-10 1:50 ` Anton Blanchard
2004-09-10 2:22 ` William Lee Irwin III
2004-09-10 2:32 ` William Lee Irwin III
2004-09-10 2:37 ` William Lee Irwin III
2004-09-10 3:24 ` Anton Blanchard
2004-09-10 7:40 ` Ingo Molnar
2004-09-10 12:16 ` William Lee Irwin III
2004-09-10 12:22 ` Ingo Molnar
2004-09-10 3:23 ` Anton Blanchard
2004-09-10 7:56 ` Anton Blanchard
2004-09-13 0:45 [PATCH] Yielding processor resources during lock contention Nakajima, Jun
2004-09-13 1:35 Nakajima, Jun
2004-09-13 6:35 ` Ingo Molnar
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.58.0409112200060.13491@ppc970.osdl.org \
--to=torvalds@osdl.org \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=anton@samba.org \
--cc=jun.nakajima@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulus@samba.org \
--cc=zwane@fsmlabs.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
all inboxes | Powered by JetHome®