From: Rusty Russell <rusty@rustcorp.com.au>
To: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>,
linux-kernel@vger.kernel.org, Russell King <rmk@arm.linux.org.uk>,
Bryan Wu <cooloney@kernel.org>, Tony Luck <tony.luck@intel.com>,
Ralf Baechle <ralf@linux-mips.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mundt <lethal@linux-sh.org>,
"David S. Miller" <davem@davemloft.net>,
Arnd Bergmann <arnd@arndb.de>,
anton@samba.org, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Mike Travis <travis@sgi.com>
Subject: Re: [PATCH 2/5] cpumask: make task_struct.cpus_allowed a cpumask_var_t
Date: Mon, 28 Jun 2010 19:01:26 +0930 [thread overview]
Message-ID: <201006281901.27517.rusty@rustcorp.com.au> (raw)
In-Reply-To: <alpine.DEB.2.00.1006251058180.18900@router.home>
On Sat, 26 Jun 2010 01:30:25 am Christoph Lameter wrote:
> On Fri, 25 Jun 2010, Rusty Russell wrote:
>
> > Even better would be to point to the fixed "one cpu" and "all cpus"
> > masks where possible, and make a copy when setting it to something
> > else. But you'd have to track down those naughty places which frob it
> > directly...
>
> Put it into a read only segment?
Well, I was thinking of an audit as the first step :)
> What is the estimated performance impact of adding a level of indirection
> (and a potential cache miss) to a number of critical code paths?
Unknown. Originally, I moved the mask to the end of the struct (so we could
under-allocate for the CPUMASK_OFFSTACK nr_cpu_ids < NR_CPUS case), but Ingo
didn't want to change the struct for the non-CPUMASK_OFFSTACK case.
Measurements welcome...
Rusty.
prev parent reply other threads:[~2010-06-28 9:31 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-25 13:03 [PATCH 2/5] cpumask: make task_struct.cpus_allowed a cpumask_var_t Rusty Russell
2010-06-25 16:00 ` Christoph Lameter
2010-06-28 9:31 ` Rusty Russell [this message]
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=201006281901.27517.rusty@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=anton@samba.org \
--cc=arnd@arndb.de \
--cc=benh@kernel.crashing.org \
--cc=cl@linux-foundation.org \
--cc=cooloney@kernel.org \
--cc=davem@davemloft.net \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=ralf@linux-mips.org \
--cc=rmk@arm.linux.org.uk \
--cc=tony.luck@intel.com \
--cc=travis@sgi.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.