[lkml]   [2022]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH 1/5] sched/fair: record overloaded cpus
On 2/24/22 3:10 PM, Gautham R. Shenoy wrote:
> Hello Abel,
> (+ Aubrey Li, Srikar)
> On Thu, Feb 17, 2022 at 11:43:57PM +0800, Abel Wu wrote:
>> An CFS runqueue is considered overloaded when there are
>> more than one pullable non-idle tasks on it (since sched-
>> idle cpus are treated as idle cpus). And idle tasks are
>> counted towards rq->cfs.idle_h_nr_running, that is either
>> assigned SCHED_IDLE policy or placed under idle cgroups.
>> The overloaded cfs rqs can cause performance issues to
>> both task types:
>> - for latency critical tasks like SCHED_NORMAL,
>> time of waiting in the rq will increase and
>> result in higher pct99 latency, and
>> - batch tasks may not be able to make full use
>> of cpu capacity if sched-idle rq exists, thus
>> presents poorer throughput.
>> The mask of overloaded cpus is updated in periodic tick
>> and the idle path at the LLC domain basis. This cpumask
>> will also be used in SIS as a filter, improving idle cpu
>> searching.
> This is an interesting approach to minimise the tail latencies by
> keeping track of the overloaded cpus in the LLC so that
> idle/sched-idle CPUs can pull from them. This approach contrasts with the
> following approaches that were previously tried :
> 1. Maintain the idle cpumask at the LLC level by Aubrey Li
> 2. Maintain the identity of the idle core itself at the LLC level, by Srikar :
> There have been concerns in the past about having to update the shared
> mask/counter at regular intervals. Srikar, Aubrey any thoughts on this
> ?

 \ /
  Last update: 2022-02-27 09:09    [W:0.185 / U:0.392 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site