linux-kernel - Re: [RFC PATCH] sched/fair: update the vruntime to be max vruntime when yield

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <43e91964-cd34-2e84-03a3-3903aa94c5e6@arm.com>
Date:   Wed, 1 Mar 2023 12:23:45 +0100
From:   Dietmar Eggemann <dietmar.eggemann@....com>
To:     Xuewen Yan <xuewen.yan94@...il.com>,
        Vincent Guittot <vincent.guittot@...aro.org>
Cc:     Qais Yousef <qyousef@...alina.io>,
        Peter Zijlstra <peterz@...radead.org>,
        Xuewen Yan <xuewen.yan@...soc.com>, mingo@...hat.com,
        juri.lelli@...hat.com, rostedt@...dmis.org, bsegall@...gle.com,
        mgorman@...e.de, bristot@...hat.com, vschneid@...hat.com,
        linux-kernel@...r.kernel.org, ke.wang@...soc.com,
        zhaoyang.huang@...soc.com
Subject: Re: [RFC PATCH] sched/fair: update the vruntime to be max vruntime
 when yield

Hi Xuewen,

On 01/03/2023 09:20, Xuewen Yan wrote:
> On Wed, Mar 1, 2023 at 4:09 PM Vincent Guittot
> <vincent.guittot@...aro.org> wrote:
>>
>> On Wed, 1 Mar 2023 at 08:30, Xuewen Yan <xuewen.yan94@...il.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
        }
} 

[...]