linux-kernel - Re: [PATCH 11/13] sched_ext: Add scx

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: <aRJiR7H3RQHmgCct@slm.duckdns.org>
Date: Mon, 10 Nov 2025 12:08:07 -1000
From: Tejun Heo <tj@...nel.org>
To: Andrea Righi <arighi@...dia.com>
Cc: David Vernet <void@...ifault.com>, Changwoo Min <changwoo@...lia.com>,
	Dan Schatzberg <schatzberg.dan@...il.com>,
	Emil Tsalapatis <etsal@...a.com>, sched-ext@...ts.linux.dev,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 11/13] sched_ext: Add scx_cpu0 example scheduler

Hello,

On Mon, Nov 10, 2025 at 10:06:29PM +0100, Andrea Righi wrote:
> I agree that if a scheduler uses SCX_SLICE_DFL it shouldn't care too much
> about the exact value.
> 
> My concern was more about those schedulers that are quite paranoid about
> latency and even if something isn't handled properly (directly dispatching
> to a wrong CPU, a task being rescheduled internally, etc.), we'd still have
> a guarantee that a task's time slice can't exceed a known upper bound. But
> this could be managed by being able to set a default time slice (somehow)
> and it can be addressed separately.
> 
> So yeah, in this case the exact value of SCX_SLICE_DFL doesn't really
> matter probably.

AFAICS, all cases where we use the default slice can be avoided by setting
the right SCX_OPS_ENQ_ flags and not letting through tasks with zero slice.
ie. If the scheduler needs to control slice distribution closely, it can do
so and, if something leaks, that can be detected through the events although
it may be helpful to add a strict mode where these leaks can be tracked down
more easily.

This is not necessarily an argument against making the default slice
configurable. The fact that we use the default slice for bypassing was a
reason to be more cautious with exposing it (as that can affect system
recoverability) but with bypass slice separated out, that's less of a
concern too. So, yeah, I think making it ops configurable is fine too.

Thanks.

-- 
tejun