netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Abeni <pabeni@redhat.com>
To: Eric Dumazet <edumazet@google.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Hannes Frederic Sowa <hannes@stressinduktion.org>,
	netdev <netdev@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Jiri Pirko <jiri@mellanox.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Alexei Starovoitov <ast@plumgrid.com>,
	Alexander Duyck <aduyck@mirantis.com>,
	Tom Herbert <tom@herbertland.com>, Ingo Molnar <mingo@kernel.org>,
	Rik van Riel <riel@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: Re: [RFC PATCH 0/2] net: threadable napi poll loop
Date: Mon, 16 May 2016 15:10:32 +0200	[thread overview]
Message-ID: <1463404232.4921.26.camel@redhat.com> (raw)
In-Reply-To: <CANn89iJER4ziKLsAkSpKMRKBtHApzsHOnSndXJn2oTsf_01beA@mail.gmail.com>

On Fri, 2016-05-13 at 10:36 -0700, Eric Dumazet wrote:
> On Fri, May 13, 2016 at 10:19 AM, Paolo Abeni <pabeni@redhat.com> wrote:
> 
> > The difference is small, in the noise range:
> >
> > [with this patch applied]
> > super_netperf 100 -H 192.168.122.1 -t UDP_STREAM -l 60 -- -m 1
> > 9.00
> >
> > [adding the test into __local_bh_enable_ip(), too]
> > super_netperf 100 -H 192.168.122.1 -t UDP_STREAM -l 60 -- -m 1
> > 9.14
> >
> > but reproducible, in my experiments.
> > I have similar data for different number of flows.
> >
> >> I believe I did this so that we factorize the logic in do_softirq()
> >> and keep the code local to kernel/softirq.c
> >>
> >> Otherwise, netif_rx_ni() could also process softirq while ksoftirqd
> >> was scheduled,
> >> so I would have to  'export' the ksoftirqd_running(void) helper in an
> >> include file.
> >
> > The idea could be to add the test in __local_bh_enable_ip(), maintaining
> > the test also in do_softirq() (as currently done, i.e for
> > local_softirq_pending())
> >
> 
> Then I guess even the !in_interrupt() test we do is expensive and
> could be avoided,
> since do_softirq() is doing it again in the unlikely case it really is needed.
> 
> @@ -162,7 +170,8 @@ void __local_bh_enable_ip(unsigned long ip,
> unsigned int cnt)
>          */
>         preempt_count_sub(cnt - 1);
> 
> -       if (unlikely(!in_interrupt() && local_softirq_pending())) {
> +       if (unlikely(local_softirq_pending()) &&
> +                    !ksoftirqd_running()) {
>                 /*
>                  * Run softirq if any pending. And do it in its own stack
>                  * as we may be calling this deep in a task call stack already.

I'm sorry for the not-so-prompt reply. I had to use a different H/W, so
I had to re-run the tests with all the patch flavors to get comparable
results.

While I can confirm that adding the '!ksoftirqd_running()' condition
improves the throughput a little, but in a reproducible way, removing
the '!in_interrupt()' don't change the result measurably, in my
environment.

While running the test against a kernel with the above chunk applied I
got a couple of:

[  702.791025] NOHZ: local_softirq_pending 08

Not seen with the other versions of this patch.

Cheers,

Paolo

  reply	other threads:[~2016-05-16 13:10 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-10 14:11 [RFC PATCH 0/2] net: threadable napi poll loop Paolo Abeni
2016-05-10 14:11 ` [RFC PATCH 1/2] net: implement threaded-able napi poll loop support Paolo Abeni
2016-05-10 14:11 ` [RFC PATCH 2/2] net: add sysfs attribute to control napi threaded mode Paolo Abeni
2016-05-10 14:29 ` [RFC PATCH 0/2] net: threadable napi poll loop Eric Dumazet
2016-05-10 15:51   ` David Miller
2016-05-10 16:03   ` Paolo Abeni
2016-05-10 16:08     ` Eric Dumazet
2016-05-10 20:22       ` Paolo Abeni
2016-05-10 20:45         ` David Miller
2016-05-10 20:50           ` Rik van Riel
2016-05-10 20:52             ` David Miller
2016-05-10 21:01               ` Rik van Riel
2016-05-10 20:46   ` Hannes Frederic Sowa
2016-05-10 21:09     ` Eric Dumazet
2016-05-10 21:31       ` Eric Dumazet
2016-05-10 21:35         ` Rik van Riel
2016-05-10 21:53           ` Eric Dumazet
2016-05-10 22:02             ` Eric Dumazet
2016-05-10 22:44               ` Eric Dumazet
2016-05-10 22:02             ` Rik van Riel
2016-05-11 17:55             ` Eric Dumazet
2016-05-10 22:32       ` Hannes Frederic Sowa
2016-05-10 22:51         ` Eric Dumazet
2016-05-11  6:55           ` Peter Zijlstra
2016-05-11 13:13             ` Hannes Frederic Sowa
2016-05-11 14:40               ` Eric Dumazet
2016-05-11 15:01                 ` Rik van Riel
2016-05-11 15:50                 ` Eric Dumazet
2016-05-11 21:56             ` Eric Dumazet
2016-05-12 20:07               ` Paolo Abeni
2016-05-12 20:49                 ` Eric Dumazet
2016-05-12 20:58                   ` Paolo Abeni
2016-05-12 21:05                     ` Eric Dumazet
2016-05-13 16:50               ` Paolo Abeni
2016-05-13 17:03                 ` Eric Dumazet
2016-05-13 17:19                   ` Paolo Abeni
2016-05-13 17:36                     ` Eric Dumazet
2016-05-16 13:10                       ` Paolo Abeni [this message]
2016-05-16 13:38                         ` Eric Dumazet
2016-05-11  9:48           ` Paolo Abeni
2016-05-11 13:08             ` Eric Dumazet
2016-05-11 13:39               ` Hannes Frederic Sowa
2016-05-11 13:47                 ` Hannes Frederic Sowa
2016-05-11 14:38               ` Paolo Abeni
2016-05-11 14:45                 ` Eric Dumazet
2016-05-11 22:47                   ` Hannes Frederic Sowa
2016-05-10 15:57 ` Thomas Gleixner
2016-05-10 20:41   ` Paolo Abeni

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=1463404232.4921.26.camel@redhat.com \
    --to=pabeni@redhat.com \
    --cc=aduyck@mirantis.com \
    --cc=ast@plumgrid.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=eric.dumazet@gmail.com \
    --cc=hannes@stressinduktion.org \
    --cc=jiri@mellanox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=riel@redhat.com \
    --cc=tom@herbertland.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;
as well as URLs for NNTP newsgroup(s).