linux-kernel - Re: [PATCH v2 1/1] sched/deadline: Fix dl

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <b28fe126340b4a5e63b21f131ee70806e673d83b.camel@mediatek.com>
Date: Thu, 26 Jun 2025 11:20:57 +0800
From: Kuyo Chang <kuyo.chang@...iatek.com>
To: John Stultz <jstultz@...gle.com>
CC: Ingo Molnar <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>,
	Juri Lelli <juri.lelli@...hat.com>, Vincent Guittot
	<vincent.guittot@...aro.org>, Dietmar Eggemann <dietmar.eggemann@....com>,
	Steven Rostedt <rostedt@...dmis.org>, Ben Segall <bsegall@...gle.com>, "Mel
 Gorman" <mgorman@...e.de>, Valentin Schneider <vschneid@...hat.com>, Matthias
 Brugger <matthias.bgg@...il.com>, AngeloGioacchino Del Regno
	<angelogioacchino.delregno@...labora.com>, <linux-kernel@...r.kernel.org>,
	<linux-arm-kernel@...ts.infradead.org>, <linux-mediatek@...ts.infradead.org>,
	"Team, Android" <kernel-team@...roid.com>
Subject: Re: [PATCH v2 1/1] sched/deadline: Fix dl_server runtime
 calculation formula

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@...gle.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