All of lore.kernel.org
 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 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.