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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPjX3FfW=0imU+fkrM05ipv8VtFc9urX4B9EeCNk0WenjjqzTg@mail.gmail.com>
Date: Tue, 6 Jan 2026 17:38:17 +0100
From: Daniel Vacek <neelx@...e.com>
To: Valentin Schneider <vschneid@...hat.com>
Cc: Shrikanth Hegde <sshegde@...ux.ibm.com>, Aaron Tomlin <atomlin@...mlin.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, 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.