From: cruzzhao <cruzzhao@linux.alibaba.com>
To: Josh Don <joshdon@google.com>
Cc: Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Benjamin Segall <bsegall@google.com>,
Mel Gorman <mgorman@suse.de>,
Daniel Bristot de Oliveira <bristot@redhat.com>,
Alexey Dobriyan <adobriyan@gmail.com>,
Eric Dumazet <edumazet@google.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 2/2] sched/core: Uncookied force idle accounting per cpu
Date: Wed, 5 Jan 2022 19:33:48 +0800 [thread overview]
Message-ID: <8be4679f-632b-97e5-9e48-1e1a37727ddf@linux.alibaba.com> (raw)
In-Reply-To: <CABk29NsP+sMQPRwS2e3zoeBsX1+p2aevFFO+i9GdB5VQ0ujEbA@mail.gmail.com>
在 2022/1/5 上午9:56, Josh Don 写道:
> Hi Cruz,
>
> On Thu, Dec 23, 2021 at 4:30 AM Cruz Zhao <CruzZhao@linux.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.).
next prev parent reply other threads:[~2022-01-05 11:33 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-23 12:30 [PATCH 0/2] Forced idle time accounting per cpu Cruz Zhao
2021-12-23 12:30 ` [PATCH 1/2] sched/core: Cookied forceidle " Cruz Zhao
2022-01-05 1:48 ` Josh Don
2022-01-05 11:33 ` cruzzhao
2022-01-05 20:47 ` Josh Don
2022-01-06 12:09 ` cruzzhao
2022-01-06 19:49 ` Josh Don
2021-12-23 12:30 ` [PATCH 2/2] sched/core: Uncookied force idle " Cruz Zhao
2022-01-05 1:56 ` Josh Don
2022-01-05 11:33 ` cruzzhao [this message]
2022-01-05 20:59 ` Josh Don
2022-01-06 12:05 ` cruzzhao
2022-01-06 20:03 ` Josh Don
2021-12-23 12:40 ` [PATCH 0/2] Forced idle time " cruzzhao
2022-01-04 7:15 ` cruzzhao
2022-01-04 17:58 ` Josh Don
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8be4679f-632b-97e5-9e48-1e1a37727ddf@linux.alibaba.com \
--to=cruzzhao@linux.alibaba.com \
--cc=adobriyan@gmail.com \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=edumazet@google.com \
--cc=joshdon@google.com \
--cc=juri.lelli@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=vincent.guittot@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).