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

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

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?

Best,
Juri