linux-kernel - Re: [PATCH 1/2] sched: Interrupt Aware Scheduler

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:   Fri, 12 May 2017 21:46:58 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Rohit Jain <rohit.k.jain@...cle.com>
Cc:     linux-kernel@...r.kernel.org, mingo@...hat.com,
        Morten Rasmussen <morten.rasmussen@....com>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Vincent Guittot <vincent.guittot@...aro.org>
Subject: Re: [PATCH 1/2] sched: Interrupt Aware Scheduler

On Fri, May 12, 2017 at 11:04:26AM -0700, Rohit Jain wrote:
> The patch avoids CPUs which might be considered interrupt-heavy when
> trying to schedule threads (on the push side) in the system. Interrupt
> Awareness has only been added into the fair scheduling class.
> 
> It does so by, using the following algorithm:
> --------------------------------------------------------------------------
> 1) When the interrupt is getting processed, the start and the end times
> are noted for the interrupt on a per-cpu basis.

IRQ_TIME_ACCOUNTING you mean?

> 2) On a periodic basis the interrupt load is processed for each run
> queue and this is mapped in terms of percentage in a global array. The
> interrupt load for a given CPU is also decayed over time, so that the
> most recent interrupt load has the biggest contribution in the interrupt
> load calculations. This would mean the scheduler will try to avoid CPUs
> (if it can) when scheduling threads which have been recently busy with
> handling hardware interrupts.

You mean like like how its already added to rt_avg? Which is then used
to lower a CPU's capacity.

> 3) Any CPU which lies above the 80th percentile in terms of percentage
> interrupt load is considered interrupt-heavy.
> 
> 4) During idle CPU search from the scheduler perspective this
> information is used to skip CPUs if better are available.
> 
> 5) If none of the CPUs are better in terms of idleness and interrupt
> load, then the interrupt-heavy CPU is considered to be the best
> available CPU.

I would much rather you work with the EAS people and extend the capacity
awareness of those code paths. Then, per the existing logic, things
should just work out.

It doesn't matter how the capacity is lowered, at some point you just
don't want to put tasks on. It really doesn't matter if that's because
IRQs, SoftIRQs, (higher priority) Real-Time tasks, thermal throttling or
anything else.