From: Gautham R Shenoy <ego@in.ibm.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org,
Rusty Russel <rusty@rustcorp.com.au>,
Srivatsa Vaddagiri <vatsa@in.ibm.com>,
Dipankar Sarma <dipankar@in.ibm.com>, Ingo Molnar <mingo@elte.hu>,
Oleg Nesterov <oleg@tv-sign.ru>,
Paul E McKenney <paulmck@us.ibm.com>,
Richard Gooch <rgooch@atnf.csiro.au>,
Tigran Aivazian <tigran@aivazian.fs.co.uk>,
Shoahua Li <shaohua.li@linux.com>,
Ralf Baechle <ralf@linux-mips.org>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Nathan Lynch <ntl@pobox.com>, David Miller <davem@davemloft.net>,
Paul Jackson <pj@sgi.com>, Josh Triplett <josh@freedesktop.org>,
Pekka Enberg <penberg@cs.helsinki.fi>,
Akinobu Mita <akinobu.mita@gmail.com>
Subject: Re: [RFC PATCH 0/5] Refcount based Cpu Hotplug. V2
Date: Wed, 24 Oct 2007 23:30:34 +0530 [thread overview]
Message-ID: <20071024180034.GB8663@in.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0710241001160.26202@schroedinger.engr.sgi.com>
On Wed, Oct 24, 2007 at 10:04:41AM -0700, Christoph Lameter wrote:
> On Wed, 24 Oct 2007, Gautham R Shenoy wrote:
>
> > This is the version 2 of the refcount based cpu-hotplug "locking"
> > implementation.
>
> Uggh. This introduces a global lock that has to be taken always when
> scanning over cpus?
Well, no! we take the global lock only while bumping up the refcount.
We don't hold the lock while scanning over the cpus. And this is
definitely an improvement over the lock_cpu_hotplug() global mutex
we have now.
>Is multipe cpus are scanning over processor lists then
> we will get into scaling problems. Wasnt there an RCU based implementation
> that avoided cacheline bouncing and refcounting?
Oh yes! You are probably refering to
http://lkml.org/lkml/2006/10/26/73
which was posted a year ago. Unfortunately it didn't get much review,
and we moved on towards a bunch of other implementations.
Anyway, the first step would be to move away from locks towards
a refcount model. Later on we can use rcu + per-cpu refcounts thereby
making it scalable on the read side.
>
> > The patchstack which is based against 2.6.23-mm1 has behaved well
> > when it was stress tested with kernbench running while continuously
> > performing cpu-hotplug operations on i386, x86_64 and ppc64.
>
> What was the highest cpu count in testing?
8 cpus on i386 and x86_64.
16 cpus on ppc64.
Thanks and Regards
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!"
next prev parent reply other threads:[~2007-10-25 7:01 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-24 5:29 [RFC PATCH 0/5] Refcount based Cpu Hotplug. V2 Gautham R Shenoy
2007-10-24 5:30 ` [RFC PATCH 1/5] Refcount Based Cpu Hotplug implementation Gautham R Shenoy
2007-10-24 5:32 ` [RFC PATCH 2/5] Replace lock_cpu_hotplug() with get_online_cpus() Gautham R Shenoy
2007-10-24 5:34 ` [RFC PATCH 3/5] Replace per-subsystem mutexes " Gautham R Shenoy
2007-10-24 5:37 ` [RFC PATCH 4/5] Remove CPU_DEAD/CPU_UP_CANCELLED handling from workqueue.c Gautham R Shenoy
2007-10-24 7:21 ` Rusty Russell
2007-10-24 8:35 ` Gautham R Shenoy
2007-10-24 13:44 ` Oleg Nesterov
2007-10-24 13:38 ` Oleg Nesterov
2007-10-24 17:45 ` Gautham R Shenoy
2007-10-24 18:14 ` Oleg Nesterov
2007-10-24 5:39 ` [RFC PATCH 5/5] Update get_online_cpus() in Documentation/cpu-hotplug.c Gautham R Shenoy
2007-10-24 17:04 ` [RFC PATCH 0/5] Refcount based Cpu Hotplug. V2 Christoph Lameter
2007-10-24 18:00 ` Gautham R Shenoy [this message]
2007-10-24 18:17 ` Oleg Nesterov
2007-10-24 18:22 ` Gautham R Shenoy
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=20071024180034.GB8663@in.ibm.com \
--to=ego@in.ibm.com \
--cc=akinobu.mita@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=clameter@sgi.com \
--cc=davem@davemloft.net \
--cc=dipankar@in.ibm.com \
--cc=heiko.carstens@de.ibm.com \
--cc=josh@freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=ntl@pobox.com \
--cc=oleg@tv-sign.ru \
--cc=paulmck@us.ibm.com \
--cc=penberg@cs.helsinki.fi \
--cc=pj@sgi.com \
--cc=ralf@linux-mips.org \
--cc=rgooch@atnf.csiro.au \
--cc=rusty@rustcorp.com.au \
--cc=shaohua.li@linux.com \
--cc=tigran@aivazian.fs.co.uk \
--cc=torvalds@linux-foundation.org \
--cc=vatsa@in.ibm.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