Re: [PATCH v2] sched/deadline: Make dl-server nohz full aware

[Juri Lelli <juri.lelli@redhat.com>]

On 01/10/26 14:57, Frederic Weisbecker wrote:
> Le Fri, Sep 25, 2026 at 05:07:51PM +0200, Juri Lelli a écrit :
> > Hi Ionut,
> > 
> > On 24/09/26 20:02, Ionut Nechita (Wind River) wrote:
> > > Hi Juri,
> > > 
> > > I have been chasing timer noise on isolated nohz_full cores for an RT
> > > product and ended up on this patch. It does restore the CFS bandwidth
> > > guarantee, but on the isolated core itself it trades the dl-server's
> > > timers for a full CONFIG_HZ tick, which for us is the more expensive of
> > > the two.
> > > 
> > > Below are measurements from two machines, a variant that keeps the core
> > > tickless, and a hazard in the dl_servers_stop_all() call sites that an
> > > equivalent change of mine ran into. The variant is not a replacement for
> > > your patch as it stands, since it does not address the housekeeping
> > > wakeups you are fixing, so this is more a "can we get both?" than a
> > > counter-proposal.
> > 
> > Thanks for the detailed analysis!
> > 
> > I believe my v2 was never picked up, so I'm happy for you to send a v3
> > modified with your approach. Keeping the tick stopped during the
> > server's throttled window sounds reasonable to me. Having a proper
> > single patch will make it easier to evaluate. Please do include the
> > ext_server handling as well so we have the complete picture.
> > 
> > ...
> > 
> > > A separate observation
> > > ======================
> > > 
> > > Independently of either patch, the CFS wakeup pattern changed between
> > > v6.12 and v6.18. With the same workload, v6.12 serves the periodic CFS
> > > task every ~50ms (199 wakeups in 10s), while both v6.18 variants on that
> > > machine serve it once per server period (10 wakeups in 10s, ~1s worst
> > > case). The bandwidth is the same, but it arrives in one burst per period
> > > instead of being spread out. For an isolated core running a periodic
> > > housekeeping task next to an RT application, that is a user-visible
> > > change. Is the deferred activation expected to behave this way, or is it
> > > worth looking at separately?
> > 
> > I think what you see is the deferred server model at work. The server
> > now defers activation until zero-laxity. The dl-server is primarily a
> > safety net to prevent complete CFS starvation under RT, not a latency
> > guarantee, so the bandwidth being correct (5%) is what matters and how
> > it's distributed within the period is a secondary concern. That said, if
> > I understand your example correctly, that periodic housekeeping CFS task
> > you have on the same isolated core of the RT application is relying on
> > dl-server to be able to run? It doesn't seem a safe approach to me, the
> > RT application should better ensure to sleep at times leaving space for
> > CFS housekeeping task to execute w/o activating the dl-server?
> 
> I'm not sure I understand everything in this matter but in general
> sched bandwidth is incompatible with nohz_full. It's about a single task
> running so there shouldn't need to limit access to the CPU. And therefore
> there should be no dl_server running there, right?

But dl-server gets activated in case a fair task gets enqueued on a cpu
in nohz_full mode currently running a FIFO task (so that that fair task
will get a chance to run in case the FIFO task won't sleep).