linux-kernel - Re: [PATCH v2 06/10] sched/debug: Add support to change sched

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: <aECTCyILPeWF1gvX@slm.duckdns.org>
Date: Wed, 4 Jun 2025 08:40:11 -1000
From: Tejun Heo <tj@...nel.org>
To: Juri Lelli <juri.lelli@...hat.com>
Cc: Joel Fernandes <joelagnelf@...dia.com>, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	Dietmar Eggemann <dietmar.eggemann@....com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
	Valentin Schneider <vschneid@...hat.com>,
	David Vernet <void@...ifault.com>, Andrea Righi <arighi@...dia.com>,
	Changwoo Min <changwoo@...lia.com>
Subject: Re: [PATCH v2 06/10] sched/debug: Add support to change sched_ext
 server params

On Wed, Jun 04, 2025 at 12:02:11PM +0200, Juri Lelli wrote:
> Hi Joel,
> 
> On 02/06/25 14:01, Joel Fernandes wrote:
> > When a sched_ext server is loaded, tasks in CFS are converted to run in
> > sched_ext class. Modify the ext server parameters as well along with the
> > fair ones.
> > 
> > Re-use the existing interface to modify both ext and fair servers to
> > keep number of interfaces less (as it is, we have a per-cpu interface).
> 
> We have a bit of code duplication, don't we? I wonder if we can do
> anything early on to prevent mis-alignment between servers in the
> future.
> 
> Also, is a single shared interface enough? Is the assumption that either
> all tasks are FAIR or SCX always guaranteed?

It's not a guarantee but at least all the current use cases are like that.
No objection to splitting the interface tho. In fact, for SCX, it may make
more sense to just make it part of sched_ext_ops, so that each scheduler can
specify what they want.

Thanks.

-- 
tejun