Re: [PATCH 1/1] sched/deadline: Log Fair Server re-enablement for symmetry with debugfs

[K Prateek Nayak <kprateek.nayak@amd.com>]

Hello Aaron,

On 1/9/2026 8:00 PM, Aaron Tomlin wrote:
> Consider a strictly partitioned environment utilising isolcpus=domain,5-8
> alongside nohz_full=5-8. A latency-critical SCHED_FIFO task executing on
> CPU 5 that never enters the kernel requires absolute isolation. If a
> SCHED_NORMAL (CFS) task is enqueued - perhaps a CPU-specific kthread or
> some other user-specific task - the current architecture wakes the Deadline
> Server, which in turn restarts the clock-tick - see sched_can_stop_tick().
> By temporarily disabling the Fair Server via the debug interface, an
> administrator can preclude this interruption during a specific, sensitive
> window of execution, before restoring standard operation once the critical
> phase has concluded.

I believe the suggested solution to that was to trace the reason for the
kthread/fair task waking up on isolated CPUs and prevent the wakeup if
it is for some unnecessary operation as opposed to disabling the fair
server.

We have tools like https://docs.kernel.org/trace/osnoise-tracer.html to
capture these noise. Trace the noise, bring up the case where isolation
is broken on the current *upstream* kernel to the mailing list, and we
can solve it for everyone instead of disabling fair server as a duct
tape.

[..snip..]

>> I still think once the fair server is disabled, the pieces are for the
>> user to keep. I wouldn't want us debugging:
>>
>>     Fair server disabled in CPU X ...
>>     Fair server re-enabled in CPU X ...
>>     INFO: rcu_tasks detected stalls ...
>>
>> only to realise the stalls were a result of starving the fair threads
>> and the fair server didn't run in time / didn't have enough B/W to
>> prevent that stall.

[..snip..]
> Regarding your concern about debugging RCU stalls and the "keep the pieces"
> philosophy: I would argue that this is precisely why the symmetry in
> logging is essential.

I would argue that fiddling with the fair server is a terrible idea and
once the user disables it, all bets are off. It becomes their headache
to solve.

> 
> Without the "re-enabled" marker, the audit trail is incomplete. If a system
> stalls, seeing only a "Fair server disabled" message leaves the duration of
> the starvation event ambiguous. By explicitly logging the re-enablement, we
> establish a definitive timeline. If an RCU stall occurs shortly after the
> server is re-enabled, the timestamp provides the necessary evidence to
> correlate the crash directly with the preceding starvation
> period — confirming that the user's intervention was indeed the root cause.
> Transparency, in this case, expedites the diagnosis of "user-induced"
> failure.

Juri, Peter, is changing the fair server's bandwidth frequently very
common scenario is the field?

If not, can we add a pr_warn() for when the fair server's parameters
are changed by the userspace just to catch any absurd values that
reduce the bandwidth to a minimum without disabling the server?

I can do something absolutely stupid like this without dmesg logging
anything that would indicate I'm being stupid:

    # echo 4000000000 > /sys/kernel/debug/sched/fair_server/cpu0/period
    # echo 1 > /sys/kernel/debug/sched/fair_server/cpu0/runtime
    # sudo taskset -c 0 chrt -r 99 ~/scripts/loop&
    # taskset -c 0 bash -c 'mkdir /sys/fs/cgroup/cg0; echo $$ > /sys/fs/cgroup/cg0/cgroup.procs;'

    ... wait for a while

     INFO: task bash:4272 blocked for more than 120 seconds.
           Not tainted 6.19.0-rc1-tip+ #162
     "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
     task:bash            state:D stack:0     pid:4272  tgid:4272  ppid:4271   task_flags:0x400100 flags:0x00080000


A taint might be too far but a log should be acceptable?

-- 
Thanks and Regards,
Prateek