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  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 <>
To:     Rohit Jain <>
        Morten Rasmussen <>,
        Dietmar Eggemann <>,
        Vincent Guittot <>
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.


> 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.

Powered by blists - more mailing lists