On 16/02/25 16:33, Qais Yousef wrote: > On 02/13/25 07:20, Juri Lelli wrote: > > On 12/02/25 19:22, Dietmar Eggemann wrote: > > > On 11/02/2025 11:42, Juri Lelli wrote: > > > > ... > > > > > > What about we actually ignore them consistently? We already do that for > > > > admission control, so maybe we can do that when rebuilding domains as > > > > well (until we find maybe a better way to deal with them). > > > > > > > > Does the following make any difference? > > > > > > It at least seems to solve the issue. And like you mentioned on irc, we > > > don't know the bw req of sugov anyway. > > > > > > So with this change we start with 'dl_bw->total_bw = 0' even w/ sugov tasks. > > > > > > dl_rq[0]: > > > .dl_nr_running : 0 > > > .dl_bw->bw : 996147 > > > .dl_bw->total_bw : 0 <-- ! > > > > > > IMHO, people who want to run serious DL can always check whether there > > > are already these infrastructural DL tasks or even avoid schedutil. > > > > It definitely not ideal and admittedly gross, but not worse than what we > > are doing already considering we ignore sugovs at AC and the current > > bandwidth allocation its there only to help with PI. So, duck tape. :/ > > > > A more proper way to work with this would entail coming up with sensible > > bandwidth allocation for sugovs, but that's most probably hardware > > specific, so I am not sure how we can make that general enough. > > I haven't been following the problem closely, but one thing I was considering > and I don't know if it makes sense to you and could help with this problem too. > Shall we lump sugov with stopper class or create a new sched_class (seems > unnecessary, I think stopper should do)? With the consolidate cpufreq update > patch I've been working on Vincent raised issues with potential new ctx switch > and to improve that I needed to look at improving sugov wakeup path. If we > decouple it from DL I think that might fix your problem here and could allow us > to special case it for other problems like the ones I faced more easily without > missing up with DL. > > Has the time come to consider retire the simple solution of making sugov a fake > DL task? Problem is that 'ideally' we would want to explicitly take sugovs into account when designing the system. We don't do that currently as a 'temporary solution' that seemed simpler than a proper approach (started wondering if it's indeed simpler). So, not sure if moving sugovs outside DL is something we want to do. Thanks, Juri
