From: Eric Dumazet <eric.dumazet@gmail.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: Christoph Lameter <cl@linux.com>, Tejun Heo <tj@kernel.org>,
akpm@linuxfoundation.org, Steven Rostedt <srostedt@redhat.com>,
linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
netdev@vger.kernel.org
Subject: Re: [pchecks v1 2/4] Use raw cpu ops for calls that would trigger with checks
Date: Tue, 24 Sep 2013 05:45:04 -0700 [thread overview]
Message-ID: <1380026704.3165.56.camel@edumazet-glaptop> (raw)
In-Reply-To: <20130924073250.GD28538@gmail.com>
On Tue, 2013-09-24 at 09:32 +0200, Ingo Molnar wrote:
> (netdev Cc:-ed)
>
> * Christoph Lameter <cl@linux.com> wrote:
>
> > These location triggered during testing with KVM.
> >
> > These are fetches without preemption off where we judged that
> > to be more performance efficient or where other means of
> > providing synchronization (BH handling) are available.
>
> > Index: linux/include/net/snmp.h
> > ===================================================================
> > --- linux.orig/include/net/snmp.h 2013-09-12 13:26:29.216103951 -0500
> > +++ linux/include/net/snmp.h 2013-09-12 13:26:29.208104037 -0500
> > @@ -126,7 +126,7 @@ struct linux_xfrm_mib {
> > extern __typeof__(type) __percpu *name[SNMP_ARRAY_SZ]
> >
> > #define SNMP_INC_STATS_BH(mib, field) \
> > - __this_cpu_inc(mib[0]->mibs[field])
> > + raw_cpu_inc(mib[0]->mibs[field])
> >
> > #define SNMP_INC_STATS_USER(mib, field) \
> > this_cpu_inc(mib[0]->mibs[field])
> > @@ -141,7 +141,7 @@ struct linux_xfrm_mib {
> > this_cpu_dec(mib[0]->mibs[field])
> >
> > #define SNMP_ADD_STATS_BH(mib, field, addend) \
> > - __this_cpu_add(mib[0]->mibs[field], addend)
> > + raw_cpu_add(mib[0]->mibs[field], addend)
>
> Are the networking folks fine with allowing unafe operations of SNMP stats
> in preemptible sections, or should the kernel produce an optional warning
> message if CONFIG_PREEMPT_DEBUG=y and these ops are used in preemptible
> (non-bh, non-irq-handler, non-irqs-off, etc.) sections?
>
> RAW_SNMP_*_STATS() ops could be used to annotate those places where that
> kind of usage is safe.
I would rather not use RAW_ prefix in the macro, but add debugging
check to make sure we use _BH() variant in the right context.
BUG_ON(!in_softirq())
prev parent reply other threads:[~2013-09-24 12:45 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20130923191256.584672290@linux.com>
[not found] ` <000001414c3d064a-ebe0610b-6951-4a74-bd33-8480e3e1e364-000000@email.amazonses.com>
2013-09-24 7:32 ` [pchecks v1 2/4] Use raw cpu ops for calls that would trigger with checks Ingo Molnar
2013-09-24 12:45 ` Eric Dumazet [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=1380026704.3165.56.camel@edumazet-glaptop \
--to=eric.dumazet@gmail.com \
--cc=akpm@linuxfoundation.org \
--cc=cl@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=srostedt@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox