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] [day] [month] [year] [list]
Message-ID: <be4f14be-0872-420d-9639-ad64961f7477@efficios.com>
Date:   Mon, 16 Oct 2023 15:24:45 -0400
From:   Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:     Chen Yu <yu.c.chen@...el.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
        Valentin Schneider <vschneid@...hat.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Juri Lelli <juri.lelli@...hat.com>,
        Swapnil Sapkal <Swapnil.Sapkal@....com>,
        Aaron Lu <aaron.lu@...el.com>, Tim Chen <tim.c.chen@...el.com>,
        K Prateek Nayak <kprateek.nayak@....com>,
        "Gautham R . Shenoy" <gautham.shenoy@....com>, x86@...nel.org
Subject: Re: [RFC PATCH] sched/fair: Introduce WAKEUP_BIAS_PREV_IDLE to reduce
 migrations

On 2023-10-15 11:44, Chen Yu wrote:
> On 2023-10-12 at 16:36:26 -0400, Mathieu Desnoyers wrote:
>> Introduce the WAKEUP_BIAS_PREV_IDLE scheduler feature to reduce the
>> task migration rate.
>>
>> For scenarios where the system is under-utilized (CPUs are partly idle),
>> eliminate frequent task migrations from almost idle CPU to completely
>> idle CPUs by introducing a bias towards the previous CPU if it is idle
>> or almost idle in select_idle_sibling(). Use 1% of the CPU capacity
>> of the previously used CPU as CPU utilization "almost idle" cutoff.
>>
>> +
>> +/*
>> + * A runqueue is considered almost idle if:
>> + *
>> + *   cpu_util_without(cpu, p) / 1024 <= 1% * capacity_of(cpu)
> 
> util_avg is in the range [0:1024], thus cpu_util_without(cpu, p) / 1024
> is <= 1, and 1% * cap is 10, so 1 <= 10 is always true.
> I suppose you want to compare:
>   (cpu_util_without(cpu, p) / capacity_orig_of(cpu)) <= 1% ->
>      cpu_util_without(cpu, p) * 100 <= capacity_orig_of(cpu) ?

Good point!

Now that I have fixed this, I come back to a situation where:

- load_avg works, probably because it multiplies by the weight, and 
therefore when there are few tasks on the runqueue it reflects the fact 
that the runqueue is almost idle. Even though it happens to work, it 
does not appear to be an elegant solution.

- util_avg and runnable_avg do not work. Probably because they take into 
account both running/runnable and recently blocked tasks, so they cannot 
be used to provide a clear picture of the very-short-term idleness 
status for the purpose of selecting a prev rq.

I wonder if there are any rq stats I can use which do not include 
recently blocked tasks ?

Thanks,

Mathieu


> 
> thanks,
> Chenyu
>   
> 

-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ