Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1640715

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

From Peter Zijlstra <peterz@infradead.org>
Newsgroups linux.kernel
Subject Re: [PATCH 1/2] sched: Interrupt Aware Scheduler
Date 2017-05-12 21:50 +0200
Message-ID <tGoJA-YD-5@gated-at.bofh.it> (permalink)
References <tGnaN-8qN-7@gated-at.bofh.it> <tGnaN-8qN-5@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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.

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH 1/2] sched: Interrupt Aware Scheduler Rohit Jain <rohit.k.jain@oracle.com> - 2017-05-12 20:10 +0200
  Re: [PATCH 1/2] sched: Interrupt Aware Scheduler Peter Zijlstra <peterz@infradead.org> - 2017-05-12 21:50 +0200
    Re: [PATCH 1/2] sched: Interrupt Aware Scheduler Rohit Jain <rohit.k.jain@oracle.com> - 2017-05-12 22:20 +0200
      Re: [PATCH 1/2] sched: Interrupt Aware Scheduler Vincent Guittot <vincent.guittot@linaro.org> - 2017-05-17 10:00 +0200
        Re: [PATCH 1/2] sched: Interrupt Aware Scheduler Rohit Jain <rohit.k.jain@oracle.com> - 2017-05-18 19:30 +0200

csiph-web