From: Chen Yu <yu.c.chen@intel.com>
To: Josh Don <joshdon@google.com>
Cc: Yicong Yang <yangyicong@huawei.com>, <yangyicong@hisilicon.com>,
"Vincent Guittot" <vincent.guittot@linaro.org>,
Joel Fernandes <joel@joelfernandes.org>,
Honglei Wang <wanghonglei@didichuxing.com>,
"Peter Zijlstra" <peterz@infradead.org>,
Tim Chen <tim.c.chen@intel.com>,
Mel Gorman <mgorman@techsingularity.net>,
Juri Lelli <juri.lelli@redhat.com>,
"Rik van Riel" <riel@surriel.com>, Aaron Lu <aaron.lu@intel.com>,
Abel Wu <wuyun.abel@bytedance.com>,
K Prateek Nayak <kprateek.nayak@amd.com>,
"Gautham R . Shenoy" <gautham.shenoy@amd.com>,
Ingo Molnar <mingo@redhat.com>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
"Steven Rostedt" <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>,
"Daniel Bristot de Oliveira" <bristot@redhat.com>,
Valentin Schneider <vschneid@redhat.com>,
Hillf Danton <hdanton@sina.com>, Len Brown <len.brown@intel.com>,
Chen Yu <yu.chen.surf@gmail.com>,
Tianchen Ding <dtcccc@linux.alibaba.com>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 1/2] sched/fair: Introduce short duration task check
Date: Tue, 13 Dec 2022 13:46:26 +0800 [thread overview]
Message-ID: <Y5gRsnLQLlzugB4I@chenyu5-mobl1> (raw)
In-Reply-To: <CABk29NvsBbqop20Z8-mdnZpto+Znc_+93OK9dsVMcimsSOf1xQ@mail.gmail.com>
On 2022-12-12 at 10:17:35 -0800, Josh Don wrote:
> > BTW, I've changed the threshold to (sysctl_sched_min_granularity / 8) in my next
> > version, as this is the value that fit my previous test case and also not to break
> > the case Josh mentioned.
>
> Do you mean a hardcoded value of some number of micros, or literally
> sched_min_granularity / 8?
The latter. According to the test, the average task duration when system
is under heavy load:
6 ~ 9 us for netperf
7 ~ 70 us for hackbench
7 ~ 8 us for tbench
13 ~ 20 ms for schbench
Overall the duration of the micros are quite small(except for schbench).
The default sysctl_sched_min_granularity is 750 us in kernel if no user
has changed it. Then 750 / 8 = 93 us, which is close to what you suggested(100us).
On the other hand, if someone changes sysctl_sched_min_granularity,
then '8' can be viewed as log2(256). That is, if there are 256 CPUs online,
and the sysctl_sched_min_granularity is changed to 750 us * log2(256) by
the user, we can devide the sysctl_sched_min_granularity by 8 in case the
sysctl_sched_min_granularity is too large.
My concern of using hardcoded value is that, this value depends on how fast
the CPU runs(cpu frequency). The value I measured above is when the
CPU is running at 1.9Ghz. If a CPU runs faster, a hard code value might not
be appropriate and could not be tuned.
> I don't think the latter is necessary, and
> indeed can lead to weirdness if min_gran is too small or too large. I
> don't think the concept of what a short duration task is should
> expand/contract with min_gran.
The value of sysctl_sched_min_granularity might indicate how long the
user would like a task to run at least. If the user enlarge this value,
does it mean the user wants every task in the system to run longer?
From this point I found connection between the the definition of short task
duration and this value. I'm open to changing this value to a fixed one, may
I have more insights on how this value would be set in production environment?
thanks,
Chenyu
>
> Best,
> Josh
next prev parent reply other threads:[~2022-12-13 5:47 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-01 8:43 [PATCH v3 0/2] sched/fair: Choose the CPU where short task is running during wake up Chen Yu
2022-12-01 8:44 ` [PATCH v3 1/2] sched/fair: Introduce short duration task check Chen Yu
2022-12-02 7:44 ` Honglei Wang
2022-12-03 7:49 ` Chen Yu
2022-12-03 15:35 ` Joel Fernandes
2022-12-05 8:38 ` Chen Yu
2022-12-05 9:59 ` Vincent Guittot
2022-12-05 14:38 ` Chen Yu
2022-12-07 2:23 ` Josh Don
2022-12-07 14:24 ` Chen Yu
2022-12-12 11:22 ` Yicong Yang
2022-12-12 14:33 ` Chen Yu
2022-12-12 18:17 ` Josh Don
2022-12-13 5:46 ` Chen Yu [this message]
2022-12-13 10:06 ` Honglei Wang
2022-12-13 12:24 ` Chen Yu
2022-12-01 8:44 ` [PATCH v3 2/2] sched/fair: Choose the CPU where short task is running during wake up Chen Yu
2022-12-03 17:20 ` kernel test robot
2022-12-05 2:36 ` Tianchen Ding
2022-12-05 8:40 ` Chen Yu
2022-12-06 13:02 ` Yicong Yang
2022-12-07 3:54 ` Chen Yu
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=Y5gRsnLQLlzugB4I@chenyu5-mobl1 \
--to=yu.c.chen@intel.com \
--cc=aaron.lu@intel.com \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=dtcccc@linux.alibaba.com \
--cc=gautham.shenoy@amd.com \
--cc=hdanton@sina.com \
--cc=joel@joelfernandes.org \
--cc=joshdon@google.com \
--cc=juri.lelli@redhat.com \
--cc=kprateek.nayak@amd.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@techsingularity.net \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=riel@surriel.com \
--cc=rostedt@goodmis.org \
--cc=tim.c.chen@intel.com \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=wanghonglei@didichuxing.com \
--cc=wuyun.abel@bytedance.com \
--cc=yangyicong@hisilicon.com \
--cc=yangyicong@huawei.com \
--cc=yu.chen.surf@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.