From: Eric Dumazet <eric.dumazet@gmail.com>
To: Christoph Lameter <cl@linux.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] percpu_counter: change inaccurate comment
Date: Thu, 07 Oct 2010 22:42:11 +0200 [thread overview]
Message-ID: <1286484131.3745.88.camel@edumazet-laptop> (raw)
In-Reply-To: <alpine.DEB.2.00.1010071509180.28032@router.home>
Le jeudi 07 octobre 2010 à 15:13 -0500, Christoph Lameter a écrit :
> On Thu, 7 Oct 2010, Eric Dumazet wrote:
>
> > If enclosed by preempt_disable()/preempt_enable(), maybe we could use
> > __this_cpu_ptr() ?
>
> The only difference between __this_cpu_ptr and this_cpu_ptr is that
> this_cpu_ptr checks that preempt was disabled. __this_cpu_ptr allows use
> even without preempt. Preempt must be disabled here so the use of
> this_cpu_ptr is appropriate.
>
>
Thats not how I read the thing.
In both variants, preemption _must_ be disabled, its only the context
that can tell how sure we are...
<quote>
commit 7340a0b15280c
__this_cpu_ptr -> Do not check for preemption context
this_cpu_ptr -> Check preemption context
</quote>
If preemption was enabled, both pointers would not be very useful...
We use __this_cpu_ptr() in contexts where cpu _cannot_ change under us,
(we just disabled preemption one line above), so its not necessary to
perform the check.
vi +316 include/linux/percpu.h
#define _this_cpu_generic_to_op(pcp, val, op) \
do { \
preempt_disable(); \
*__this_cpu_ptr(&(pcp)) op val; \
preempt_enable(); \
} while (0)
...
#define __this_cpu_generic_to_op(pcp, val, op) \
do { \
*__this_cpu_ptr(&(pcp)) op val; \
} while (0)
next prev parent reply other threads:[~2010-10-07 20:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-07 16:37 [PATCH] percpu_counter: change inaccurate comment Eric Dumazet
2010-10-07 19:42 ` Christoph Lameter
2010-10-07 20:04 ` Eric Dumazet
2010-10-07 20:13 ` Christoph Lameter
2010-10-07 20:42 ` Eric Dumazet [this message]
2010-10-07 21:06 ` Christoph Lameter
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=1286484131.3745.88.camel@edumazet-laptop \
--to=eric.dumazet@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=linux-kernel@vger.kernel.org \
/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.