From: Andrea Arcangeli <andrea@suse.de>
To: William Lee Irwin III <wli@holomorphy.com>,
Jack Steiner <steiner@sgi.com>,
linux-kernel@vger.kernel.org
Subject: Re: RCU scaling on large systems
Date: Fri, 7 May 2004 21:59:06 +0200 [thread overview]
Message-ID: <20040507195906.GI3829@dualathlon.random> (raw)
In-Reply-To: <20040507181706.GR1397@holomorphy.com>
On Fri, May 07, 2004 at 11:17:06AM -0700, William Lee Irwin III wrote:
> On Sat, May 01, 2004 at 02:17:04PM -0700, William Lee Irwin III wrote:
> >> Would something like this help cacheline contention? This uses the
> >> per_cpu data areas to hold per-cpu booleans for needing switches.
> >> Untested/uncompiled.
> >> The global lock is unfortunately still there.
>
> On Fri, May 07, 2004 at 07:53:58PM +0200, Andrea Arcangeli wrote:
> > I'm afraid this cannot help, the rcu_cpu_mask and the mutex are in the same
> > cacheline, so it's not just about the global lock being still there,
> > it's about the cpumask being in the same cacheline with the global lock.
>
> Hmm. I can't quite make out what you're trying to say. If it were about
> the cpumask sharing the cacheline with the global lock, then the patch
> would help, but you say it should not. I don't care much about the
Since cpumask and global lock are on the same cacheline, and the global
lock still force that cacheline to bounce, it shouldn't make any
difference to remove the cpumask from that global cacheline, by the time
you take the lock you have the cacheline local and in the next
nanosecond you can use the cpumask zerocost. I understood the real cost
is the bouncing of _such_ cacheline across all 512 cpus and the global
lock will still generates it as far as I can tell. Though I'm mostly
guessing, I certainly wouldn't be against trying your patch, I was just
afraid it cannot help.
next prev parent reply other threads:[~2004-05-07 20:02 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-01 12:08 RCU scaling on large systems Jack Steiner
2004-05-01 21:17 ` William Lee Irwin III
2004-05-01 22:35 ` William Lee Irwin III
2004-05-02 1:38 ` Jack Steiner
2004-05-07 17:53 ` Andrea Arcangeli
2004-05-07 18:17 ` William Lee Irwin III
2004-05-07 19:59 ` Andrea Arcangeli [this message]
2004-05-07 20:49 ` Jack Steiner
2004-05-02 18:28 ` Paul E. McKenney
2004-05-03 16:39 ` Jesse Barnes
2004-05-03 20:04 ` Paul E. McKenney
2004-05-03 18:40 ` Jack Steiner
2004-05-07 20:50 ` Paul E. McKenney
2004-05-07 22:06 ` Jack Steiner
2004-05-07 23:32 ` Andrew Morton
2004-05-08 4:55 ` Jack Steiner
2004-05-17 21:18 ` Andrea Arcangeli
2004-05-17 21:42 ` Andrew Morton
2004-05-17 23:50 ` Andrea Arcangeli
2004-05-18 13:33 ` Jack Steiner
2004-05-18 23:13 ` Matt Mackall
-- strict thread matches above, loose matches on Subject: below --
2004-05-20 11:36 Manfred Spraul
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=20040507195906.GI3829@dualathlon.random \
--to=andrea@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=steiner@sgi.com \
--cc=wli@holomorphy.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