linux-kernel - Re: [PATCH] sched/fair: set the se->vlag strictly following the paper

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: <cf675887-49e0-45a9-9008-33c0c6f1edf1@amperemail.onmicrosoft.com>
Date: Fri, 20 Jun 2025 11:00:45 +0800
From: Shijie Huang <shijie@...eremail.onmicrosoft.com>
To: Vincent Guittot <vincent.guittot@...aro.org>,
 Huang Shijie <shijie@...amperecomputing.com>
Cc: mingo@...hat.com, peterz@...radead.org, patches@...erecomputing.com,
 cl@...ux.com, yang@...amperecomputing.com, juri.lelli@...hat.com,
 dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
 mgorman@...e.de, vschneid@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sched/fair: set the se->vlag strictly following the paper


On 2025/6/19 21:53, Vincent Guittot wrote:
> On Thu, 19 Jun 2025 at 05:20, Huang Shijie
> <shijie@...amperecomputing.com> wrote:
>>  From the paper, the lag should follow the limit:
>>       -r_max < lag < max(r_max, q)
>>
>> But current code makes the lag follow the limit:
>>       -max(r_max, q) < lag < max(r_max, q)
>>
>> This patch introduces limit_hi/limit_lo/r_max, and
>> make the lag follow the paper strictly.
> We don't strictly follow the paper. Typically, paper assumes that a
> task will not run more than its slice r before deciding which task is
> the next to run. But this is not our case as we must wait for a sched
> event like the tick before picking next  task which can be longer than
> the slice r
>
> Side note, we don't have a fix definition of the quantum q which is
> something between 0 and a tick (and even more currently with run to
> parity) as we wait for the next the tick to pick another task
>
> This means that a task can run a full tick period even if its slice is
> shorter than the tick period

Thanks for the explanations.

But if we enable the HRTICK, the task will run to match its slice.


Thanks

Huang Shijie