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

[Frederic Weisbecker]

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?

-- 
Frederic Weisbecker
SUSE Labs