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] [day] [month] [year] [list]

Message-ID: <CAKfTPtCg7vLxQbTjeRodnbhj3sCo_zThcvS4cWBe-q2tgXi+cg@mail.gmail.com>
Date: Fri, 20 Jun 2025 08:37:29 +0200
From: Vincent Guittot <vincent.guittot@...aro.org>
To: Shijie Huang <shijie@...eremail.onmicrosoft.com>
Cc: Huang Shijie <shijie@...amperecomputing.com>, 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 Fri, 20 Jun 2025 at 05:01, Shijie Huang
<shijie@...eremail.onmicrosoft.com> wrote:
>
>
> 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.

Yes, but I'm curious to see the impact of irq time accounting on this
as the time will not be fully accounted as the slice

>
>
> Thanks
>
> Huang Shijie
>