linux-kernel - Re: [PATCH] sched: fair: make V move forward only

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: <20251128092923.GC3245006@noisy.programming.kicks-ass.net>
Date: Fri, 28 Nov 2025 10:29:23 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: wangtao <tao.wangtao@...or.com>
Cc: mingo@...hat.com, juri.lelli@...hat.com, vincent.guittot@...aro.org,
	dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
	mgorman@...e.de, vschneid@...hat.com, linux-kernel@...r.kernel.org,
	liulu.liu@...or.com, bintian.wang@...or.com
Subject: Re: [PATCH] sched: fair: make V move forward only

On Fri, Nov 28, 2025 at 04:11:18PM +0800, wangtao wrote:
> V is the weighted average of entities. Adding tasks with positive lag or
> removing tasks with negative lag may cause V to move backward. This will
> result in unfair task scheduling,

Have you actually read the paper? Why do you think this breaks fairness?

> causing previously eligible tasks to become ineligible, shorter
> runtimes, and more task switches.

None of that is a fairness issue. Those are issues related to when,
rather than how much time is given.

> Making V move forward only resolves such issues and simplifies the code
> for adding tasks with positive lag.

It breaks a metric ton of math. Which you don't provide updates for.

Yes, the paper is light on dynamic behaviour, but please don't disregard
the math like this. Either stay inside the constraints laid out, or
provide coherent alternatives. Notably EEVDF is in the same class of
scheduling functions as WF2Q and both provide better lag bounds than the
simpler WFQ class of schedulers.

The 'zero-lag point is the weighted average of the entities' is a fairly
core tenet of EEVDF. Mucking with this *will* mess with the lag bounds.

The delayed dequeue feature tries to address some of these concerns by
keeping non-eligible (negative lag) tasks on the runqueue until such
time that they become eligible (approximated by getting picked again) at
which point they get removed (and any positive lag gets truncated, as if
they were removed at zero-lag). As a consequence you will have much less
removal of negative lag, additionally such tasks will be eligible the
moment they come back.

Also, there is the small matter that your patch simply does not apply.