All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [PATCH] virtio_net: invoke softirqs after __napi_schedule
Date: Thu, 17 May 2012 13:02:53 +0930	[thread overview]
Message-ID: <87vcjvzdlm.fsf@rustcorp.com.au> (raw)
In-Reply-To: <20120516075712.GA2921@redhat.com>

On Wed, 16 May 2012 10:57:13 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> __napi_schedule might raise softirq but nothing
> causes do_softirq to trigger, so it does not in fact
> run. As a result,
> the error message "NOHZ: local_softirq_pending 08"
> sometimes occurs during boot of a KVM guest when the network service is
> started and we are oom:
> 
>   ...
>   Bringing up loopback interface:  [  OK  ]
>   Bringing up interface eth0:
>   Determining IP information for eth0...NOHZ: local_softirq_pending 08
>    done.
>   [  OK  ]
>   ...
> 
> Further, receive queue processing might get delayed
> indefinitely until some interrupt triggers:
> virtio_net expected napi to be run immediately.
> 
> One way to cause do_softirq to be executed is by
> invoking local_bh_enable(). As __napi_schedule is
> normally called from bh or irq context, this
> seems to make sense: disable bh before __napi_schedule
> and enable afterwards.
> 
> Reported-by: Ulrich Obergfell <uobergfe@redhat.com>
> Tested-by: Ulrich Obergfell <uobergfe@redhat.com>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> 
> To test, one can hack try_fill_recv to always report oom.
> I'm not sure it's not too late for 3.4, but we can try.
> Rusty, could you review ASAP pls?

It's missing a big comment: it's a very complicated way of calling
do_softirq().

Indeed, this function is only used when we are not in interrupt
context.  It's not hot at all, in any ideal scenario.

Acked-by: Rusty Russell <rusty@rustcorp.com.au>

WARNING: multiple messages have this Message-ID (diff)
From: Rusty Russell <rusty@rustcorp.com.au>
To: "Michael S. Tsirkin" <mst@redhat.com>,
	David Miller <davem@davemloft.net>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	virtualization@lists.linux-foundation.org,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] virtio_net: invoke softirqs after __napi_schedule
Date: Thu, 17 May 2012 13:02:53 +0930	[thread overview]
Message-ID: <87vcjvzdlm.fsf@rustcorp.com.au> (raw)
In-Reply-To: <20120516075712.GA2921@redhat.com>

On Wed, 16 May 2012 10:57:13 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> __napi_schedule might raise softirq but nothing
> causes do_softirq to trigger, so it does not in fact
> run. As a result,
> the error message "NOHZ: local_softirq_pending 08"
> sometimes occurs during boot of a KVM guest when the network service is
> started and we are oom:
> 
>   ...
>   Bringing up loopback interface:  [  OK  ]
>   Bringing up interface eth0:
>   Determining IP information for eth0...NOHZ: local_softirq_pending 08
>    done.
>   [  OK  ]
>   ...
> 
> Further, receive queue processing might get delayed
> indefinitely until some interrupt triggers:
> virtio_net expected napi to be run immediately.
> 
> One way to cause do_softirq to be executed is by
> invoking local_bh_enable(). As __napi_schedule is
> normally called from bh or irq context, this
> seems to make sense: disable bh before __napi_schedule
> and enable afterwards.
> 
> Reported-by: Ulrich Obergfell <uobergfe@redhat.com>
> Tested-by: Ulrich Obergfell <uobergfe@redhat.com>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> 
> To test, one can hack try_fill_recv to always report oom.
> I'm not sure it's not too late for 3.4, but we can try.
> Rusty, could you review ASAP pls?

It's missing a big comment: it's a very complicated way of calling
do_softirq().

Indeed, this function is only used when we are not in interrupt
context.  It's not hot at all, in any ideal scenario.

Acked-by: Rusty Russell <rusty@rustcorp.com.au>

WARNING: multiple messages have this Message-ID (diff)
From: Rusty Russell <rusty@rustcorp.com.au>
To: "Michael S. Tsirkin" <mst@redhat.com>,
	David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [PATCH] virtio_net: invoke softirqs after __napi_schedule
Date: Thu, 17 May 2012 13:02:53 +0930	[thread overview]
Message-ID: <87vcjvzdlm.fsf@rustcorp.com.au> (raw)
In-Reply-To: <20120516075712.GA2921@redhat.com>

On Wed, 16 May 2012 10:57:13 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> __napi_schedule might raise softirq but nothing
> causes do_softirq to trigger, so it does not in fact
> run. As a result,
> the error message "NOHZ: local_softirq_pending 08"
> sometimes occurs during boot of a KVM guest when the network service is
> started and we are oom:
> 
>   ...
>   Bringing up loopback interface:  [  OK  ]
>   Bringing up interface eth0:
>   Determining IP information for eth0...NOHZ: local_softirq_pending 08
>    done.
>   [  OK  ]
>   ...
> 
> Further, receive queue processing might get delayed
> indefinitely until some interrupt triggers:
> virtio_net expected napi to be run immediately.
> 
> One way to cause do_softirq to be executed is by
> invoking local_bh_enable(). As __napi_schedule is
> normally called from bh or irq context, this
> seems to make sense: disable bh before __napi_schedule
> and enable afterwards.
> 
> Reported-by: Ulrich Obergfell <uobergfe@redhat.com>
> Tested-by: Ulrich Obergfell <uobergfe@redhat.com>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> 
> To test, one can hack try_fill_recv to always report oom.
> I'm not sure it's not too late for 3.4, but we can try.
> Rusty, could you review ASAP pls?

It's missing a big comment: it's a very complicated way of calling
do_softirq().

Indeed, this function is only used when we are not in interrupt
context.  It's not hot at all, in any ideal scenario.

Acked-by: Rusty Russell <rusty@rustcorp.com.au>

  reply	other threads:[~2012-05-17  3:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-16  7:57 [PATCH] virtio_net: invoke softirqs after __napi_schedule Michael S. Tsirkin
2012-05-16  7:57 ` Michael S. Tsirkin
2012-05-17  3:32 ` Rusty Russell [this message]
2012-05-17  3:32   ` Rusty Russell
2012-05-17  3:32   ` Rusty Russell
2012-05-17  3:40   ` David Miller
2012-05-17  3:40     ` David Miller

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=87vcjvzdlm.fsf@rustcorp.com.au \
    --to=rusty@rustcorp.com.au \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=virtualization@lists.linux-foundation.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.