Control: retitle -1 rt: NAPI softirq not being scheduled properly Control: tag -1 upstream
On Mon, 2012-08-20 at 11:06 +0300, Yevgeny Kosarzhevsky wrote: > On Mon, 20 Aug 2012 04:46:53 +0100 > Ben Hutchings <b...@decadent.org.uk> wrote: > > > On Mon, 2012-07-16 at 10:48 +0000, Yevgeny Kosarhevsky wrote: > > > Package: src > > > Version: 3.2.21-3 > > > Severity: critical > > > Justification: causes serious data loss > > > > What data? > > My peers reported packet loss. Switching back to 2.6.32 kernel solved the > issue. You must accept the risk of loss of data transmitted using UDP. The phrase 'causes serious data loss' refers only to data in non-volatile storage (or that is reported as having been stored there). > > > Dear Maintainer, > > > I get a heavy load on irq/23-eth0: > > > 1086 root -51 0 0 0 0 S 2.0 0.0 0:31.04 irq/23-eth0 > > > > > > > I don't think 2% CPU time is a 'heavy load'. > > > > > This is only occured after upgrading from 2.6.32 kernel. > > > The LA was 0.00 on previous kernel, now it's 1.44 > > [...] > > > > But you are not comparing like with like. On a real-time kernel, IRQ > > handlers are scheduled as tasks and are accounted in the load average. > > On a standard kernel as you were running before, IRQ handlers are > > accounted separately. > > > > So, is there really a problem here? Did you actually mean to install a > > real-time kernel? > > Since there was a packet loss, I think there is a problem. I don't know if > it's > related with > > [ 1966.544292] NOHZ: local_softirq_pending 08 > > [ 2108.848600] NOHZ: local_softirq_pending 08 The number 08 apparently represents the NET_RX softirq, which is usually responsible for receiving packets after a network interrupt (NAPI). And this warning seems to mean that it is marked as pending, but somehow hasn't been scheduled. So this is very likely related. Ben. -- Ben Hutchings The most exhausting thing in life is being insincere. - Anne Morrow Lindberg
signature.asc
Description: This is a digitally signed message part
