linux-kernel - RE: [PATCH v5] sched/fair: Add fair placement lag

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: <b12062ebbca943dfa5634d24f1333726@honor.com>
Date: Thu, 8 Jan 2026 07:21:18 +0000
From: wangtao <tao.wangtao@...or.com>
To: "mingo@...hat.com" <mingo@...hat.com>, "peterz@...radead.org"
	<peterz@...radead.org>, "juri.lelli@...hat.com" <juri.lelli@...hat.com>,
	"vincent.guittot@...aro.org" <vincent.guittot@...aro.org>
CC: "dietmar.eggemann@....com" <dietmar.eggemann@....com>,
	"rostedt@...dmis.org" <rostedt@...dmis.org>, "bsegall@...gle.com"
	<bsegall@...gle.com>, "mgorman@...e.de" <mgorman@...e.de>,
	"vschneid@...hat.com" <vschneid@...hat.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, liulu 00013167 <liulu.liu@...or.com>,
	"wangbintian(BintianWang)" <bintian.wang@...or.com>, wangzicheng
	<wangzicheng@...or.com>
Subject: RE: [PATCH v5] sched/fair: Add fair placement lag

Hi,

Just a gentle ping on the patch I sent about two weeks ago.

  https://lore.kernel.org/all/20251222095700.6598-1-tao.wangtao@honor.com/

The patch targets question (2) in Section 4 "Fairness in Dynamic Systems"
of the EEVDF paper:

  "When a client with non-zero lag leaves the competition,
   what should be its lag when it rejoins the competition?"

Section 5 of the paper notes that there is no single clearly fair way
to handle this, and therefore presents three implementation strategies
(Strategy #1, #2, and #3) with different trade-offs. The current Linux
EEVDF implementation corresponds to Strategy #1.

The patch introduces FAIR_PLACE_LAG, which keeps V + J invariant
when there are runnable tasks, and aims to avoid the "V moving
backwards" and order-instability issues in the T1/T2/T3 example,
providing more stable and arguably fairer behavior when entities
frequently leave and rejoin. Hackbench results in the commit message
show some improvements.

Could you please take a look and let me know whether the overall
direction looks acceptable, and if exposing FAIR_PLACE_LAG as an
optional alternative to the existing Strategy #1 would be reasonable?
I'm happy to rework and send a new version if needed.

Thanks for your time.

Best regards,
Tao