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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 21 Jul 2014 19:09:13 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Jonathan Davies <jonathan.davies@...rix.com>
Cc:	Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <eric.dumazet@...il.com>
Subject: Re: [PATCH RFC] sched/core: Make idle_cpu return 0 if doing softirq
 work

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.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/