From: Dietmar Eggemann <dietmar.eggemann@arm.com>
To: Xuewen Yan <xuewen.yan94@gmail.com>,
Vincent Guittot <vincent.guittot@linaro.org>
Cc: Qais Yousef <qyousef@layalina.io>,
Peter Zijlstra <peterz@infradead.org>,
Xuewen Yan <xuewen.yan@unisoc.com>,
mingo@redhat.com, juri.lelli@redhat.com, rostedt@goodmis.org,
bsegall@google.com, mgorman@suse.de, bristot@redhat.com,
vschneid@redhat.com, linux-kernel@vger.kernel.org,
ke.wang@unisoc.com, zhaoyang.huang@unisoc.com
Subject: Re: [RFC PATCH] sched/fair: update the vruntime to be max vruntime when yield
Date: Wed, 1 Mar 2023 12:23:45 +0100 [thread overview]
Message-ID: <43e91964-cd34-2e84-03a3-3903aa94c5e6@arm.com> (raw)
In-Reply-To: <CAB8ipk9uPMxwEUHkLWbKXQEO1UkwBPWbZb=NF7AE5JHnG8V6Dw@mail.gmail.com>
Hi Xuewen,
On 01/03/2023 09:20, Xuewen Yan wrote:
> On Wed, Mar 1, 2023 at 4:09 PM Vincent Guittot
> <vincent.guittot@linaro.org> wrote:
>>
>> On Wed, 1 Mar 2023 at 08:30, Xuewen Yan <xuewen.yan94@gmail.com> wrote:
>>>
>>> Hi Vincent
>>>
>>> I noticed the following patch:
>>> https://lore.kernel.org/lkml/20230209193107.1432770-1-rkagan@amazon.de/
>>> And I notice the V2 had merged to mainline:
>>> https://lore.kernel.org/all/20230130122216.3555094-1-rkagan@amazon.de/T/#u
>>>
>>> The patch fixed the inversing of the vruntime comparison, and I see
>>> that in my case, there also are some vruntime is inverted.
>>> Do you think which patch will work for our scenario? I would be very
>>> grateful if you could give us some advice.
>>> I would try this patch in our tree.
>>
>> By default use the one that is merged; The difference is mainly a
>> matter of time range. Also be aware that the case of newly migrated
>> task is not fully covered by both patches.
>
> Okay, Thank you very much!
>
>>
>> This patch fixes a problem with long sleeping entity in the presence
>> of low weight and always running entities. This doesn't seem to be
>> aligned with the description of your use case
>
> Thanks for the clarification! We would try it first to see whether it
> could resolve our problem.
Can you not run Vincent's rt-app example on your device and then report
`cat /sys/kernel/debug/sched/debug` of the CPU?
# rt-app /root/rt-app/cfs_yield.json
# cat /sys/kernel/debug/sched/debug
...
cpu#2
.nr_running : 4
...
.curr->pid : 2121
...
cfs_rq[2]:/autogroup-15
.exec_clock : 0.000000
.MIN_vruntime : 32428.281204
.min_vruntime : 32428.281204
.max_vruntime : 32434.997784
...
.nr_running : 4
.h_nr_running : 4
...
S task PID tree-key switches prio wait-time sum-exec sum-sleep
-------------------------------------------------------------------------------------------------------------
S cpuhp/2 22 1304.405864 13 120 0.000000 0.270000 0.000000 0.000000 0 0 /
S migration/2 23 0.000000 8 0 0.000000 7.460940 0.000000 0.000000 0 0 /
S ksoftirqd/2 24 137721.092326 46 120 0.000000 1.821880 0.000000 0.000000 0 0 /
I kworker/2:0H 26 2116.827393 4 100 0.000000 0.057220 0.000000 0.000000 0 0 /
I kworker/2:1 45 204539.183593 322 120 0.000000 447.975440 0.000000 0.000000 0 0 /
I kworker/2:3 80 1778.668364 33 120 0.000000 16.237320 0.000000 0.000000 0 0 /
I kworker/2:1H 239 199388.093936 74 100 0.000000 1.892300 0.000000 0.000000 0 0 /
R taskA-0 2120 32428.281204 582 120 0.000000 1109.911280 0.000000 0.000000 0 0 /autogroup-15
>R taskB-1 2121 32430.693304 265 120 0.000000 1103.527660 0.000000 0.000000 0 0 /autogroup-15
R taskB-2 2122 32432.137084 264 120 0.000000 1105.006760 0.000000 0.000000 0 0 /autogroup-15
R taskB-3 2123 32434.997784 282 120 0.000000 1115.965120 0.000000 0.000000 0 0 /autogroup-15
...
Not sure how Vincent's rt-app file looks like exactly but I crafted
something quick here:
{
"tasks" : {
"taskA" : {
"cpus" : [2],
"yield" : "taskA",
"run" : 1000
},
"taskB" : {
"instance" : 3,
"cpus" : [2],
"run" : 1000000
}
},
"global" : {
"calibration" : 156,
"default_policy" : "SCHED_OTHER",
"duration" : 20
}
}
[...]
next prev parent reply other threads:[~2023-03-01 11:23 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-22 8:03 Xuewen Yan
2023-02-27 1:51 ` Xuewen Yan
2023-02-27 15:40 ` Peter Zijlstra
2023-02-27 16:21 ` Steven Rostedt
2023-02-27 22:07 ` Qais Yousef
2023-02-28 7:42 ` Xuewen Yan
2023-02-28 7:53 ` Vincent Guittot
2023-02-28 8:20 ` Xuewen Yan
2023-02-28 9:07 ` Vincent Guittot
2023-02-28 13:31 ` Qais Yousef
2023-02-28 13:45 ` Vincent Guittot
2023-03-01 7:30 ` Xuewen Yan
2023-03-01 8:09 ` Vincent Guittot
2023-03-01 8:20 ` Xuewen Yan
2023-03-01 11:23 ` Dietmar Eggemann [this message]
2023-03-01 13:29 ` Vincent Guittot
2023-06-30 14:40 ` Qais Yousef
2023-08-21 7:51 ` Xuewen Yan
2023-08-22 15:54 ` Vincent Guittot
2023-08-23 2:03 ` Xuewen Yan
2023-08-26 20:46 ` Qais Yousef
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=43e91964-cd34-2e84-03a3-3903aa94c5e6@arm.com \
--to=dietmar.eggemann@arm.com \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=juri.lelli@redhat.com \
--cc=ke.wang@unisoc.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=qyousef@layalina.io \
--cc=rostedt@goodmis.org \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=xuewen.yan94@gmail.com \
--cc=xuewen.yan@unisoc.com \
--cc=zhaoyang.huang@unisoc.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
all inboxes | Powered by JetHome®