linux-kernel - Re: [PATCH 2/2] sched/core: Uncookied force idle accounting per cpu

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]

Message-ID: <8be4679f-632b-97e5-9e48-1e1a37727ddf@linux.alibaba.com>
Date:   Wed, 5 Jan 2022 19:33:48 +0800
From:   cruzzhao <cruzzhao@...ux.alibaba.com>
To:     Josh Don <joshdon@...gle.com>
Cc:     Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Juri Lelli <juri.lelli@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Benjamin Segall <bsegall@...gle.com>,
        Mel Gorman <mgorman@...e.de>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        Alexey Dobriyan <adobriyan@...il.com>,
        Eric Dumazet <edumazet@...gle.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH 2/2] sched/core: Uncookied force idle accounting per cpu

在 2022/1/5 上午9:56, Josh Don 写道:
> Hi Cruz,
> 
> On Thu, Dec 23, 2021 at 4:30 AM Cruz Zhao <CruzZhao@...ux.alibaba.com> wrote:
>>
>> Forced idle can be divided into two types, forced idle with cookie'd task
>> running on it SMT sibling, and forced idle with uncookie'd task running
>> on it SMT sibling, which should be accounting to measure the cost of
>> enabling core scheduling too.
>>
>> This patch accounts the forced idle time with uncookie'd task, and the
>> sum of both.
>>
>> A few details:
>>  - Uncookied forceidle time and total forceidle time is displayed via
>>    the last two columns of /proc/stat.
>>  - Uncookied forceidle time is ony accounted when this cpu is forced
>>    idle and a sibling hyperthread is running with an uncookie'd task.
> 
When we care about capacity loss, we care about all but not some of it.
The forced idle time from uncookie'd task is actually caused by the
cookie'd task in runqueue indirectly, and it's more accurate to measure
the capacity loss with the sum of cookie'd forced idle time and
uncookie'd forced idle time, as far as I'm concerned.

Assuming cpu x and cpu y are a pair of smt siblings, consider the
following scenarios:
1. There's a cookie'd task A running on cpu x, and there're 4 uncookie'd
tasks B~E running on cpu y. For cpu x, there will be 80% forced idle
time(from uncookie'd task); for cpu y, there will be 20% forced idle
time(from cookie'd task).
2. There's a uncookie'd task A running on cpu x, and there're 4 cookie'd
tasks B~E running on cpu y. For cpu x, there will be 80% forced idle
time(from cookie'd task); for cpu y, there will be 20% forced idle
time(from uncookie'd task).
The scenario1 can recurrent by stress-ng(scenario2 can recurrent similary):
(cookie'd)taskset -c x stress-ng -c 1 -l 100
(uncookie'd)taskset -c y stress-ng -c 4 -l 100

In the above two scenarios, the capacity loss is 1 cpu, but in
scenario1, the cookie'd forced idle time tells us 20%cpu loss, in
scenario2, the cookie'd forced idle time tells us 80% forced idle time,
which are not accurate. It'll be more accurate with the sum of cookie'd
forced idle time and uncookie'd forced idle time.

Best,
Cruz Zhao

> What is the purpose/use-case to account the forced idle from
> uncookie'd tasks? The forced-idle from cookie'd tasks represents
> capacity loss due to adding in some cookie'd tasks. If forced idle is
> high, that can be rectified by making some changes to the cookie'd
> tasks (ie. their affinity, cpu budget, etc.).