From: Paul Jackson <pj@sgi.com>
To: paulmck@us.ibm.com
Cc: akpm@osdl.org, dada1@cosmosbay.com, linux-kernel@vger.kernel.org,
nickpiggin@yahoo.com.au, Simon.Derr@bull.net, ak@suse.de,
clameter@sgi.com
Subject: Re: [PATCH 04/04] Cpuset: skip rcu check if task is in root cpuset
Date: Fri, 16 Dec 2005 12:06:51 -0800 [thread overview]
Message-ID: <20051216120651.cb57ad2e.pj@sgi.com> (raw)
In-Reply-To: <20051216175201.GA24876@us.ibm.com>
Paul wrote:
> So I am not convinced that this optimization is worthwhile.
Nice analysis - thanks.
I read from your analysis that, except on alpha, we're down to
so little that it's going to be difficult on PREEMPT kernels to
discern a clear difference, and on non-PREEMPT kernels, the
rcu read lock is a no-op, so definitely not worth trying to
optimize away.
On the ia64 sn2_defconfig kernel (which is CONFIG_PREEMPT and
CONFIG_DEBUG_PREEMPT, and is the one I happen to care most about) I see
one short branch with this optimization, versus two calls, to the
add_preempt_count() and sub_preempt_count() routines, if I don't have
this optimization. These two *_preempt_count() routines in
kernel/sched.c generate 172 lines of assembly code, containing
several branches, due to the BUG checks.
So in that case (obviously not one of the cases with a huge installed
base ;) this optimization seems well worth it. One short branch is
cheaper than two subroutine calls to a couple of pages of code.
I can easily accept either way on this one - keeping or removing this
optimization. And it involves tradeoffs that vary by architecture and
configuration, but that aren't (so far as I know) worth custom per-arch
optimized code.
I'd slightly prefer to leave this optimization in, on the grounds that
it makes a worthwhile (albeit modest) improvement in the cases, and is
only trivially worse (an added short branch) in other cases.
What's your recommendation, Paul? You have far more experience here than I.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.925.600.0401
next prev parent reply other threads:[~2005-12-16 20:07 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-14 8:40 [PATCH 01/04] Cpuset: remove rcu slab cache optimization Paul Jackson
2005-12-14 8:40 ` [PATCH 02/04] Cpuset: use rcu directly optimization Paul Jackson
2005-12-16 17:55 ` Paul E. McKenney
2005-12-16 20:22 ` Paul Jackson
2005-12-14 8:40 ` [PATCH 03/04] Cpuset: mark number_of_cpusets read_mostly Paul Jackson
2005-12-14 8:40 ` [PATCH 04/04] Cpuset: skip rcu check if task is in root cpuset Paul Jackson
2005-12-16 17:52 ` Paul E. McKenney
2005-12-16 20:06 ` Paul Jackson [this message]
2005-12-17 16:47 ` Paul E. McKenney
2005-12-19 14:48 ` Paul Jackson
2005-12-19 16:04 ` CONFIG_DEBUG_PREEMPT (was: [PATCH 04/04] Cpuset: skip rcu check ...) Paul Jackson
2005-12-19 16:39 ` Greg Edwards
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=20051216120651.cb57ad2e.pj@sgi.com \
--to=pj@sgi.com \
--cc=Simon.Derr@bull.net \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=clameter@sgi.com \
--cc=dada1@cosmosbay.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
--cc=paulmck@us.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