virtio_net: invoke softirqs after __napi_schedule
Subsystems (4)
Michael S. Tsirkin
maintainerPATCH 1/1 virtio_net: invoke softirqs after __napi_schedule
__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.
---
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?
drivers/net/virtio_net.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
drivers/net/virtio_net.c +2 -0
@@ -492,7 +492,9 @@ static void virtnet_napi_enable(struct virtnet_info *vi)* We synchronize against interrupts via NAPI_STATE_SCHED */ if (napi_schedule_prep (&vi->napi)) {virtqueue_disable_cb (vi->rvq); +local_bh_disable ();__napi_schedule (&vi->napi); +local_bh_enable (); } }
Signature · 1 line
MST
Quoted 25 lines · Michael S. Tsirkin
__napi_schedulemight raise softirq but nothing
causesdo_softirqto trigger, so it does not in fact
run. As a result,
the error message "NOHZ:local_softirq_pending08"
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_pending08
done.
[ OK ]
...Further, receive queue processing might get delayed indefinitely until some interrupt triggers:
virtio_netexpected napi to be run immediately.One way to cause
do_softirqto be executed is by invokinglocal_bh_enable(). As__napi_scheduleis normally called from bh or irq context, this seems to make sense: disable bh before__napi_scheduleand enable afterwards.
Quoted 8 lines
Reported-by Ulrich Obergfell <[email protected]>Tested-by Ulrich Obergfell <[email protected]>Signed-off-by Michael S. Tsirkin <[email protected]>---
To test, one can hack
try_fill_recvto 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.
David Miller
maintainerFrom: Rusty Russell <[email protected]>
Date: Thu, 17 May 2012 13:02:53 +0930
Quoted 29 lines · Michael S. Tsirkin
Quoted 28 lines
__napi_schedulemight raise softirq but nothing
causesdo_softirqto trigger, so it does not in fact
run. As a result,
the error message "NOHZ:local_softirq_pending08"
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_pending08
done.
[ OK ]
...Further, receive queue processing might get delayed indefinitely until some interrupt triggers:
virtio_netexpected napi to be run immediately.One way to cause
do_softirqto be executed is by invokinglocal_bh_enable(). As__napi_scheduleis normally called from bh or irq context, this seems to make sense: disable bh before__napi_scheduleand enable afterwards.Reported-by Ulrich Obergfell <[email protected]>Tested-by Ulrich Obergfell <[email protected]>Signed-off-by Michael S. Tsirkin <[email protected]>
...
Quoted 1 line
Acked-by Rusty Russell <[email protected]>
Michael, you're best to submit this directly to Linus as I just made what I hope is my last push to him for 3.4 today.