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: <ww2dotjficcdctjiioyrb2jz3ytu2ybzn66i53bvp7ov54oied@us3jgl2gjuol>
Date: Tue, 6 Jan 2026 09:49:08 -0500
From: Aaron Tomlin <atomlin@...mlin.com>
To: Shrikanth Hegde <sshegde@...ux.ibm.com>
Cc: neelx@...e.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, vschneid@...hat.com
Subject: Re: [RFC PATCH 0/1] sched/fair: Feature to suppress Fair Server for
 NOHZ_FULL isolation

On Tue, Jan 06, 2026 at 02:37:49PM +0530, Shrikanth Hegde wrote:
> 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.

Hi Shrikanth,

You are entirely correct; isolcpus=domain (or isolcpus= without flags as
per housekeeping_isolcpus_setup()) indeed offers superior isolation by
removing the CPU from the scheduler load-balancing domains.

I must apologise for the omission in my previous correspondence. I
neglected to mention that our specific configuration utilises isolcpus= in
conjunction with nohz_full=.

> > However, the extant "Fair Server" (Deadline Server) architecture
> > compromises this isolation guarantee. At present, should a background
> > SCHED_OTHER task be enqueued, the scheduler initiates the Fair Server
> > (dl_server_start). As the Fair Server functions as a SCHED_DEADLINE entity,
> > its activation increments rq->dl.dl_nr_running.
> > 
> 
> There is runtime allocated to fair server. If you make them 0 on CPUs of
> interest, wouldn't that work?
> 
> /sys/kernel/debug/sched/fair_server/<cpu>/runtime

Yes, you are quite right; setting the fair server runtime to 0 (via
/sys/kernel/debug/sched/fair_server/[cpu]/runtime) does indeed achieve the
desired effect. In my testing, the SCHED_FIFO task on the fully
adaptive-tick CPU remains uninterrupted by the restored clock-tick when
this configuration is applied. Thank you.

However, I believe it would be beneficial if this scheduling feature were
available as an automatic kernel detection mechanism. While the manual
runtime adjustment works, having the kernel automatically detect the
condition - where an RT task is running and bandwidth enforcement is
disabled - would provide a more seamless and robust solution for
partitioned systems without requiring external intervention.
I may consider an improved version of the patch that includes a "Fair
server disabled" warning much like in sched_fair_server_write().


Kind regards,
-- 
Aaron Tomlin

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ