Messages in this thread | | | Date | Wed, 1 Mar 2023 12:23:45 +0100 | Subject | Re: [RFC PATCH] sched/fair: update the vruntime to be max vruntime when yield | From | Dietmar Eggemann <> |
| |
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 } }
[...]
| |