Re: [PATCH v2 1/1] sched/deadline: Fix dl_server runtime calculation formula

[Kuyo Chang <kuyo.chang@mediatek.com>]

On Wed, 2025-06-18 at 14:45 -0700, John Stultz wrote:
> 
> > 
> 
Hi 
> Coding nits aside, I put together a quick test that affines to a
> single cpu a SCHED_NORMAL and SCHED_FIFO spinner task to illustrate
> the issue.
> 
> You can quickly see the requested 50ms/sec dl_sever runtime on the
> big
> cpu, ends up being scaled out to 323ms/sec, blocking RT tasks on that
> little cpu for quite awhile.
>  
> https://urldefense.com/v3/__https://github.com/johnstultz-work/misc/blob/main/images/2025-06-18_illustration-of-problem-dl-server-scaling.png__;!!CTRNKA9wMg0ARbw!lPy4srzoAcjFBktsYnAx92nK9niGz-Im3xUxfnorT3tEv4TGg2uSPBQFEOPu2l6CrGwO-zFiuMyDz-8jcc0$
> 
> The wild thing with the example illustration of the issue above is
> that since my test uses cpu spinners, the cpufreq quickly maxes out.
> So it's only really considering the capacity scaling between the big
> (cpu 7) and little (cpu 0) cpus at their top frequency.
> 
> When I capped the cpu 0 max frequency to the lowest available,
> without
> the patch the behavior is crazy:
>  
> https://urldefense.com/v3/__https://github.com/johnstultz-work/misc/blob/main/images/2025-06-18_dl-server-scaling-with-cpufreq-lowered.png__;!!CTRNKA9wMg0ARbw!lPy4srzoAcjFBktsYnAx92nK9niGz-Im3xUxfnorT3tEv4TGg2uSPBQFEOPu2l6CrGwO-zFiuMyDA9vSf_I$
> 
> Though the image alone maybe isn't as clear, in that case we see the
> RT task once it runs ~650ms, the dl_server kicks in and blocks it and
> any other RT task from running for over *10 minutes*!
> 
> And with the fix to avoid scaling the fair_server, the results looks
> much more sane:
> https://urldefense.com/v3/__https://github.com/johnstultz-work/misc/blob/main/images/2025-06-18_with-patch-to-not-scale-dl-server-fixed.png__;!!CTRNKA9wMg0ARbw!lPy4srzoAcjFBktsYnAx92nK9niGz-Im3xUxfnorT3tEv4TGg2uSPBQFEOPu2l6CrGwO-zFiuMyDpr-NplY$
> 
> So I'm very happy to add:
>   Tested-by: John Stultz <jstultz@google.com>
> 
> And hope this gets upstream (and -stable) in some form quickly.
> 
> Thanks so much to Kuyo and others on his team for reporting and
> root-causing this issue!
> 
update to patch v3 as below
https://lore.kernel.org/all/20250626030746.2245365-1-kuyo.chang@mediatek.com/

Please help to review, and if anyone have any concerns, please let me
know.

> thanks
> -john