On Mon, 2009-10-26 at 10:47 +0200, Tilman Schmidt wrote: > > However, I lost track now of why we're discussing this. > > The starting point were several reports of the kernel message: > > NOHZ: local_softirq_pending 08 > > Originally most if not all of them came from wireless networking, > but I muddied the waters by adding to the mix a case involving ISDN. > You stated that all the solutions proposed so far were wrong, so > we're naturally turning to you for guidance on what the right > solution might be. Right. Sorry about getting lost here. > > Basically it boils down to using netif_rx() when in (soft)irq, and > > netif_rx_ni() when in process context. That could just be an > > optimisation, but it's a very valid one. > > Hmmm. That seems to contradict your earlier statement to me that > simply replacing a call to netif_rx() by one to netif_rx_ni() > when not in interrupt context isn't a valid solution either. > What am I missing? Well, I think you misunderstood me. It would be correct to do this, if and only if the code that calls it doesn't need the extra guarantee. Any code (say ISDN code) that calls netif_rx() is clearly assuming to always be running in (soft)irq context, otherwise it couldn't call netif_rx() unconditionally. Agree so far? So now if you change the ISDN code to call netif_rx_ni(), you've changed the assumption that the ISDN code makes -- that it is running in (soft)irq context. Therefore, you need to verify that this is actually a correct change, which is what I tried to say. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
