From: Andi Kleen <andi@firstfloor.org>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Shaohua Li <shaohua.li@intel.com>,
lkml <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
"hpa@zytor.com" <hpa@zytor.com>, Andi Kleen <andi@firstfloor.org>,
"Chen, Tim C" <tim.c.chen@intel.com>
Subject: Re: [PATCH 1/2]percpu: introduce read mostly percpu API
Date: Wed, 20 Oct 2010 09:35:12 +0200 [thread overview]
Message-ID: <20101020073511.GC20124@basil.fritz.box> (raw)
In-Reply-To: <1287551880.2700.79.camel@edumazet-laptop>
On Wed, Oct 20, 2010 at 07:18:00AM +0200, Eric Dumazet wrote:
> Le mercredi 20 octobre 2010 à 11:07 +0800, Shaohua Li a écrit :
> > Add a new readmostly percpu section and api, next patch will use it.
> >
> > Signed-off-by: Shaohua Li <shaohua.li@intel.com>
> > ---
>
>
> Could you precisely describe why grouping together read mostly percpu
> variables is a win ? Especially when you add in your next patch a single
> variable ?
Not Shaohua, but I can explain it:
There is some per cpu data which is read by other CPUs. In this
case it's a win to use the separate section because you avoid false sharing
and the cache line can be kept in shared mode on all CPUs.
The next patch has an example of such data: data which is read
by another CPU to send something to the target CPU.
I think the concept is useful and makes a lot of sense.
The alternative would be __read_mostly NR_CPUS arrays, but
we all know that is a bad idea because it wastes too much memory
on CONFIG_MAX_SMP setups.
-Andi
next prev parent reply other threads:[~2010-10-20 7:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-20 3:07 [PATCH 1/2]percpu: introduce read mostly percpu API Shaohua Li
2010-10-20 5:18 ` Eric Dumazet
2010-10-20 6:00 ` H. Peter Anvin
2010-10-20 7:35 ` Andi Kleen [this message]
2010-10-20 7:53 ` Eric Dumazet
2010-10-20 21:38 ` H. Peter Anvin
2010-10-20 21:42 ` H. Peter Anvin
2010-10-20 21:33 ` H. Peter Anvin
2010-10-20 23:06 ` [tip:x86/mm] percpu: Introduce a read-mostly " tip-bot for Shaohua Li
2010-10-21 1:38 ` Shaohua Li
2010-10-21 2:53 ` H. Peter Anvin
2010-10-21 5:33 ` Eric Dumazet
2010-10-21 5:54 ` H. Peter Anvin
2010-10-21 6:07 ` Eric Dumazet
2010-10-21 6:09 ` H. Peter Anvin
2010-10-21 6:17 ` Shaohua Li
2010-10-21 6:48 ` Eric Dumazet
2010-10-21 6:54 ` H. Peter Anvin
2010-10-21 6:10 ` H. Peter Anvin
2010-10-21 7:40 ` [tip:x86/mm] x86-32, percpu: Correct the ordering of the percpu readmostly section tip-bot for H. Peter Anvin
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=20101020073511.GC20124@basil.fritz.box \
--to=andi@firstfloor.org \
--cc=eric.dumazet@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=shaohua.li@intel.com \
--cc=tim.c.chen@intel.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