linux-kernel - Re: [RFC PATCH 0/1] sched/fair: Feature to suppress Fair Server for NOHZ

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: <wvnvmzo6yip5tfwadbc3xagzd5no7pwvfyq7njepevwpcr5obn@xn27o7vgwjt6>
Date: Wed, 7 Jan 2026 15:25:28 -0500
From: Aaron Tomlin <atomlin@...mlin.com>
To: Daniel Vacek <neelx@...e.com>
Cc: Valentin Schneider <vschneid@...hat.com>, 
	Shrikanth Hegde <sshegde@...ux.ibm.com>, sean@...e.io, mproche@...il.com, linux-kernel@...r.kernel.org, 
	mingo@...hat.com, peterz@...radead.org, juri.lelli@...hat.com, 
	vincent.guittot@...aro.org, dietmar.eggemann@....com, rostedt@...dmis.org, 
	bsegall@...gle.com, mgorman@...e.de
Subject: Re: [RFC PATCH 0/1] sched/fair: Feature to suppress Fair Server for
 NOHZ_FULL isolation

On Tue, Jan 06, 2026 at 05:38:17PM +0100, Daniel Vacek wrote:
> On Tue, 6 Jan 2026 at 16:38, Valentin Schneider <vschneid@...hat.com> wrote:
> > On 06/01/26 14:37, Shrikanth Hegde wrote:
> > > On 1/6/26 9:12 AM, Aaron Tomlin wrote:
> > >> Hi Ingo, Peter, Juri, Vincent,
> > >>
> > >> This patch introduces a new scheduler feature, RT_SUPPRESS_FAIR_SERVER,
> > >> designed to ensure strict NOHZ_FULL isolation for SCHED_FIFO workloads,
> > >> particularly in the presence of resident CFS tasks.
> > >>
> > >> In strictly partitioned, latency-critical environments (such as High
> > >> Frequency Trading platforms) administrators frequently employ fully
> > >> adaptive-tick CPUs to execute pinned SCHED_FIFO workloads. The fundamental
> > >> requirement is "zero OS noise"; specifically, the scheduler clock-tick must
> > >> remain suppressed ("offloaded"), given that standard SCHED_FIFO semantics
> > >> dictate no forced preemption between tasks of identical priority.
> > >
> > > If all your SCHED_FIFO is pinned and their scheduling decisions
> > > are managed in userspace, using isolcpus would offer you better
> > > isolations compared to nohz_full.
> > >
> >
> > Right, that's the part I don't get; why not use CPU isolation / cpusets to
> > isolate the CPUs running those NOHZ_FULL applications? Regardless of the
> > deadline server, if CFS tasks get scheduled on the same CPU as your
> > latency-sensitive tasks then something's not right.
> 
> Some kernel workers and threaded interrupt handlers can be local/pinned, right?
> 
> For example this is usually (was often?) visible with DPDK
> applications like FlexRAN/OpenRAN, etc.
> And Aaron has mentioned high speed trading before.

Hi Valentin, Daniel,

I must offer my apologies for the confusion; I neglected to mention in the
cover letter that isolcpus=domain is indeed deployed in this environment.

Consequently, standard load-balancing is effectively disabled. You are
quite right that standard CFS tasks should not appear on these cores; any
SCHED_NORMAL entities that do appear are not the result of leakage or
misconfiguration, but are rather unavoidable CPU-specific kthreads or
explicit migrations initiated by user-space.


Kind regards,
-- 
Aaron Tomlin

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)