linux-kernel - Re: [PATCH] sched/fair: Increase max lag clamping

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: <20250418155115.GI17910@noisy.programming.kicks-ass.net>
Date: Fri, 18 Apr 2025 17:51:15 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Vincent Guittot <vincent.guittot@...aro.org>
Cc: mingo@...hat.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: Increase max lag clamping

On Fri, Apr 18, 2025 at 05:12:25PM +0200, Vincent Guittot wrote:
> sched_entity lag is currently limited to the maximum between the tick and
> twice the slice. This is too short compared to the maximum custom slice
> that can be set and accumulated by other tasks.
> Clamp the lag to the maximum slice that a task can set. A task A can
> accumulate up to its slice of negative lag while running to parity and
> the other runnable tasks can accumulate the same positive lag while
> waiting to run. This positive lag could be lost during dequeue when
> clamping it to twice task's slice if task A's slice is 100ms and others
> use a smaller value like the default 2.8ms.
> 
> Signed-off-by: Vincent Guittot <vincent.guittot@...aro.org>
> ---
>  kernel/sched/fair.c | 16 +++++++++-------
>  1 file changed, 9 insertions(+), 7 deletions(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index a0c4cd26ee07..1c2c70decb20 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -683,15 +683,17 @@ u64 avg_vruntime(struct cfs_rq *cfs_rq)
>   * is possible -- by addition/removal/reweight to the tree -- to move V around
>   * and end up with a larger lag than we started with.
>   *
> - * Limit this to either double the slice length with a minimum of TICK_NSEC
> - * since that is the timing granularity.
> - *
> - * EEVDF gives the following limit for a steady state system:
> + * Limit this to the max allowed custom slice length which is higher than the
> + * timing granularity (the tick) and EEVDF gives the following limit for
> + * a steady state system:
>   *
>   *   -r_max < lag < max(r_max, q)
>   *
>   * XXX could add max_slice to the augmented data to track this.
>   */

Right, its that max_slice XXX there.

I think I've actually done that patch at some point, but I'm not sure
where I've placed it :-)

Anyway, I did poke at that other issue you mentioned at OSPM, where
PREEMPT_SHORT wasn't working quite right.

I've pushed out the patches to queue/sched/exp -- I meant to go post all
that, except I keep getting side-tracked and 0-day people are having
trouble with the hrtick bits in there :-/