From: Andi Kleen <ak@muc.de>
To: Kyle Moffett <mrmacman_g4@mac.com>
Cc: Chris Friesen <cfriesen@nortel.com>,
john cooper <john.cooper@timesys.com>,
linux-kernel@vger.kernel.org
Subject: Re: spinaphore conceptual draft
Date: 30 May 2005 21:28:26 +0200
Date: Mon, 30 May 2005 21:28:26 +0200 [thread overview]
Message-ID: <20050530192826.GB25794@muc.de> (raw)
In-Reply-To: <02485B05-6AE5-4727-8778-D73B2D202772@mac.com>
On Mon, May 30, 2005 at 02:04:36PM -0400, Kyle Moffett wrote:
> >I suspect any attempt to use time stamps in locks is a bad
> >idea because of this.
>
> Something like this could be built only for CPUs that do support that
> kind of cycle counter.
That gets you into a problem with binary distribution kernels.
While binary patching works to some extent, it also becomes
messy pretty quickly.
> >My impression is that the aggressive bus access avoidance the
> >original poster was trying to implement is not that useful
> >on modern systems anyways which have fast busses. Also
> >it is not even clear it even saves anything; after all the
> >CPU will always snoop cache accesses for all cache lines
> >and polling for the EXCLUSIVE transition of the local cache line
> >is probably either free or very cheap.
>
> The idea behind these locks is for bigger systems (8-way or more) for
> heavily contended locks (say 32 threads doing write() on the same fd).
Didn't Dipankar & co just fix that with their latest RCU patchkit?
(assuming you mean the FD locks)
> In such a system, cacheline snooping isn't practical at the hardware
> level, and a lock such as this should be able to send several CPUs to
Why not? Cache snooping has to always work with low overhead, otherwise the
machine is not very useful coherent. I assume that any bigger system
has a cache directory anyways, which should minimze the traffic;
and for smaller setups listening to broadcasts works fine.
-Andi
next prev parent reply other threads:[~2005-05-30 19:28 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-27 22:31 spinaphore conceptual draft (was discussion of RT patch) David Nicol
2005-05-28 1:04 ` Kyle Moffett
2005-05-29 5:25 ` David Nicol
2005-05-29 13:41 ` Kyle Moffett
2005-05-29 8:42 ` Nikita Danilov
2005-05-29 13:45 ` Kyle Moffett
2005-05-29 13:29 ` Joe Seigh
2005-05-29 15:32 ` Kyle Moffett
2005-05-30 11:06 ` spinaphore conceptual draft Andi Kleen
2005-05-30 14:52 ` Chris Friesen
2005-05-30 16:40 ` Andi Kleen
2005-05-30 17:11 ` Chris Friesen
2005-05-30 17:46 ` Andi Kleen
2005-05-30 18:04 ` Kyle Moffett
2005-05-30 18:40 ` Vojtech Pavlik
2005-05-30 18:54 ` Kyle Moffett
2005-05-30 19:24 ` Andi Kleen
2005-05-30 19:28 ` Andi Kleen [this message]
2005-05-30 19:39 ` Kyle Moffett
2005-05-31 22:25 ` Paul E. McKenney
2005-05-28 1:05 ` spinaphore conceptual draft (was discussion of RT patch) john cooper
2005-05-28 2:02 ` Steven Rostedt
2005-05-28 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=20050530192826.GB25794@muc.de \
--to=ak@muc.de \
--cc=cfriesen@nortel.com \
--cc=john.cooper@timesys.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mrmacman_g4@mac.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