From: Odin Ugedal <odin@uged.al>
To: Huaixin Chang <changhuaixin@linux.alibaba.com>
Cc: Benjamin Segall <bsegall@google.com>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
dtcccc@linux.alibaba.com, Juri Lelli <juri.lelli@redhat.com>,
khlebnikov@yandex-team.ru,
open list <linux-kernel@vger.kernel.org>,
Mel Gorman <mgorman@suse.de>, Ingo Molnar <mingo@redhat.com>,
Odin Ugedal <odin@uged.al>,
pauld@redhead.com, Peter Zijlstra <peterz@infradead.org>,
Paul Turner <pjt@google.com>,
Steven Rostedt <rostedt@goodmis.org>,
shanpeic@linux.alibaba.com, Tejun Heo <tj@kernel.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
xiyou.wangcong@gmail.com
Subject: Re: [PATCH v5 2/3] sched/fair: Add cfs bandwidth burst statistics
Date: Thu, 20 May 2021 16:11:52 +0200 [thread overview]
Message-ID: <CAFpoUr1GZspG1yKHf3D=+BZKfufWNNdu2Ccuj+YBo8EaJYRi8w@mail.gmail.com> (raw)
In-Reply-To: <20210520123419.8039-3-changhuaixin@linux.alibaba.com>
I am a bit sceptical about both the nr_burst and burst_time as they are now.
As an example; a control group using "99.9%" of the quota each period
and that is never throttled. Such group would with this patch with a burst of X
still get nr_throttled = 0 (as before), but it would get a nr_burst
and burst_time that
will keep increasing.
I think there is a big difference between runtime moved/taken from
cfs_b->runtime to cfs_rq->runtime_remaining and the actual runtime used
in the period. Currently, cfs bw can only supply info the first one, and
not the latter.
I think that if people see nr_burst increasing, that they think they _have_
to use cfs burst in order to avoid being throttled, even though that might
not be the case. It is probably fine as is, as long as it is explicitly stated
what the values mean and imply, and what they do not. I cannot see another
way to calculate it as it is now, but maybe someone else has some thoughts.
Thanks
Odin
next prev parent reply other threads:[~2021-05-20 14:15 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-20 12:34 [PATCH v5 0/3] sched/fair: Burstable CFS bandwidth controller Huaixin Chang
2021-05-20 12:34 ` [PATCH v5 1/3] sched/fair: Introduce the burstable CFS controller Huaixin Chang
2021-05-20 14:00 ` Odin Ugedal
2021-05-20 17:04 ` Tejun Heo
2021-05-21 9:09 ` changhuaixin
2021-05-21 9:38 ` Odin Ugedal
2021-05-21 12:38 ` changhuaixin
2021-05-21 14:00 ` Peter Zijlstra
2021-05-24 12:42 ` changhuaixin
2021-05-25 10:46 ` Peter Zijlstra
2021-05-31 6:59 ` luca abeni
2021-05-25 10:47 ` Peter Zijlstra
2021-05-25 21:25 ` Benjamin Segall
2021-05-25 10:49 ` Peter Zijlstra
2021-05-20 12:34 ` [PATCH v5 2/3] sched/fair: Add cfs bandwidth burst statistics Huaixin Chang
2021-05-20 14:11 ` Odin Ugedal [this message]
2021-05-21 12:42 ` changhuaixin
2021-05-21 14:05 ` Peter Zijlstra
2021-05-20 17:06 ` Tejun Heo
2021-05-21 14:01 ` Peter Zijlstra
2021-05-20 12:34 ` [PATCH v5 3/3] sched/fair: Add document for burstable CFS bandwidth Huaixin Chang
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='CAFpoUr1GZspG1yKHf3D=+BZKfufWNNdu2Ccuj+YBo8EaJYRi8w@mail.gmail.com' \
--to=odin@uged.al \
--cc=bsegall@google.com \
--cc=changhuaixin@linux.alibaba.com \
--cc=dietmar.eggemann@arm.com \
--cc=dtcccc@linux.alibaba.com \
--cc=juri.lelli@redhat.com \
--cc=khlebnikov@yandex-team.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=pauld@redhead.com \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=rostedt@goodmis.org \
--cc=shanpeic@linux.alibaba.com \
--cc=tj@kernel.org \
--cc=vincent.guittot@linaro.org \
--cc=xiyou.wangcong@gmail.com \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).