Re: [PATCH RFC] sched/core: Make idle_cpu return 0 if doing softirq work

[Peter Zijlstra <peterz@infradead.org>]

On Mon, Jul 21, 2014 at 05:56:36PM +0100, Jonathan Davies wrote:
> >If your softirq takes _that_ long its broken anyhow.
> 
> Modern NICs can sustain 40 Gb/s of traffic. For network device drivers that
> use NAPI, polling is done in softirq context. At this data-rate, the
> per-packet processing overhead means means that a lot of CPU time is spent
> in softirq.
> 
> (CCing Dave and Eric for their thoughts about long-running softirq due to
> NAPI. The example I gave above was of xen-netback sending data to another
> virtual interface at a high rate.)

So thing more or less assume that softirq handling (as ran off the tail
of hardirqs) does not take longer than a tick. Otherwise things start to
pile up and you get all kinds of nasty. Not to mention you get into
horrid latencies etc..

How hard would you scream if people ran multi tick hard interrupts? Why
do you then think its OK so do the effective same thing?

> >>Instead, the following patch is a partial solution, only handling the case when
> >>the currently-executing CPU is in softirq context. This was sufficient to solve
> >>the problem I observed.
> >
> >NAK, IRQ and SoftIRQ are outside of what the scheduler can control, so
> >for its purpose the CPU is indeed idle.
> 
> The scheduler can't control those things, but surely it wants to make the
> best possible placement for the things it can control? So it seems odd to me
> that it would ignore relevant information about the resources it can use. As
> I observed, it leads to pathological behaviour, and is easily fixed.

We already lower the compute capacity due to irq/softirq overhead, if we
don't correctly handle that then we need to fix that. But as far as the
scheduler is concerned that cpu is _IDLE_. We didn't put anything on,
and therefore there's not anything on, end of story.