On 04/19/24 14:42, Christian Loehle wrote: > > I think the major thing we need to be careful about is the behavior when the > > task is sleeping. I think the boosting will be removed when the task is > > dequeued and I can bet there will be systems out there where the BLOCK softirq > > being boosted when the task is sleeping will matter. > > Currently I see this mainly protected by the sugov rate_limit_us. > With the enqueue's being the dominating cpufreq updates it's not really an > issue, the boost is expected to survive the sleep duration, during which it > wouldn't be active. > I did experiment with some sort of 'stickiness' of the boost to the rq, but > it is somewhat of a pain to deal with if we want to remove it once enqueued > on a different rq. A sugov 1ms timer is much simpler of course. > Currently it's not necessary IMO, but for the sake of being future-proof in > terms of more frequent freq updates I might include it in v2. Making sure things work with purpose would be really great. This implicit dependency is not great IMHO and make both testing and reasoning about why things are good or bad harder when analysing real workloads. Especially by non kernel developers. > > > > > FWIW I do have an implementation for per-task iowait boost where I went a step > > further and converted intel_pstate too and like Christian didn't notice > > a regression. But I am not sure (rather don't think) I triggered this use case. > > I can't tell when the systems truly have per-cpu cpufreq control or just appear > > so and they are actually shared but not visible at linux level. > > Please do share your intel_pstate proposal! This is what I had. I haven't been working on this for the past few months, but I remember tried several tests on different machines then without a problem. I tried to re-order patches at some point though and I hope I didn't break something accidentally and forgot the state. https://github.com/torvalds/linux/compare/master...qais-yousef:linux:uclamp-max-aggregation
