From: Peter Zijlstra <peterz@infradead.org>
To: Christoph Lameter <cl@linux.com>
Cc: Tejun Heo <tj@kernel.org>,
akpm@linuxfoundation.org, rostedt@goodmis.org,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Eric Dumazet <edumazet@google.com>
Subject: Re: [PATCH 5/6] net: __this_cpu_inc in route.c
Date: Wed, 16 Oct 2013 10:46:59 +0200 [thread overview]
Message-ID: <20131016084659.GS10651@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <20131015174747.307585124@linux.com>
On Tue, Oct 15, 2013 at 12:47:27PM -0500, Christoph Lameter wrote:
> The RT_CACHE_STAT_INC macro triggers the new preemption checks
> for __this_cpu ops
>
> I do not see any other synchronization that would allow the use
> of a __this_cpu operation here however in commit
> dbd2915ce87e811165da0717f8e159276ebb803e Andrew justifies
> the use of raw_smp_processor_id() here because "we do not care"
> about races.
>
> So lets use raw_cpu ops here and hope for the best. The use of
> __this_cpu op improves the situation already from what commit
> dbd2915ce87e811165da0717f8e159276ebb803e did since the single instruction
> emitted on x86 does not allow the race to occur anymore. However,
> non x86 platforms could still experience a race here.
>
Are we sure all !x86 implementations will DTRT in that it will increment
some CPU and not get horribly confused? I suppose it would; but is
that a guarantee given someplace?
next prev parent reply other threads:[~2013-10-16 8:47 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-15 17:47 [PATCH 0/6] percpu: Implement Preemption checks for __this_cpu operations V4b Christoph Lameter
2013-10-15 17:47 ` [PATCH 1/6] net: ip4_datagram_connect: Use correct form of statistics update Christoph Lameter
2013-10-15 18:36 ` Eric Dumazet
2013-10-16 6:09 ` Ingo Molnar
2013-10-16 8:35 ` Peter Zijlstra
2013-10-16 9:14 ` Eric Dumazet
2013-10-16 9:26 ` Ingo Molnar
2013-10-16 14:27 ` Christoph Lameter
2013-10-16 14:37 ` Eric Dumazet
2013-10-15 17:47 ` [PATCH 2/6] percpu: Add raw_cpu_ops Christoph Lameter
2013-10-15 17:47 ` [PATCH 3/6] mm: Use raw_cpu ops for determining current NUMA node Christoph Lameter
2013-10-16 8:38 ` Peter Zijlstra
2013-10-16 14:22 ` Christoph Lameter
2013-10-15 17:47 ` [PATCH 4/6] Use raw_cpu_write for initialization of per cpu refcount Christoph Lameter
2013-10-16 8:43 ` Peter Zijlstra
2013-10-15 17:47 ` [PATCH 5/6] net: __this_cpu_inc in route.c Christoph Lameter
2013-10-16 8:46 ` Peter Zijlstra [this message]
2013-10-16 9:22 ` Eric Dumazet
2013-10-16 10:25 ` Peter Zijlstra
2013-10-16 15:07 ` Christoph Lameter
2013-10-15 17:47 ` [PATCH 6/6] percpu: Add preemption checks to __this_cpu ops Christoph Lameter
2013-10-16 8:49 ` Peter Zijlstra
2013-10-16 15:09 ` Christoph Lameter
2013-10-16 15:36 ` Peter Zijlstra
2013-10-16 15:55 ` Christoph Lameter
2013-10-16 16:25 ` Peter Zijlstra
2013-10-16 16:52 ` Steven Rostedt
2013-10-16 17:11 ` Peter Zijlstra
2013-10-16 17:39 ` Steven Rostedt
2013-10-16 18:38 ` Peter Zijlstra
2013-10-17 19:22 ` Christoph Lameter
2013-10-17 21:13 ` Peter Zijlstra
[not found] <20131011175518.634285474@linux.com>
2013-10-11 17:54 ` [PATCH 5/6] net: __this_cpu_inc in route.c 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=20131016084659.GS10651@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=akpm@linuxfoundation.org \
--cc=cl@linux.com \
--cc=edumazet@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=tj@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.