On Fri, Nov 12, 2021 at 11:36:08AM -0500, Johannes Weiner wrote: > On Tue, Nov 09, 2021 at 03:56:36PM +0100, Peter Zijlstra wrote: > > I think that focus on RT/IRQ is mis-guided here, and the implementation > > is horrendous. > > > > So the fundamental question seems to be; and I think Johannes is the one > > to answer that: What time-base do these metrics want to use? > > > > Do some of these states want to account in task-time instead of > > wall-time perhaps? I can't quite remember, but vague memories are > > telling me most of the PSI accounting was about blocked tasks, not > > running tasks, which makes all this rather more complicated. > > > > Randomly scaling time as proposed seems almost certainly wrong. What > > would that make the stats mean? > > It *could* be argued that IRQs and RT preemptions are CPU stalls. > > I'm less convinced we should subtract preemptions from memory stalls. > > Yes, when you're reclaiming and you get preempted for whatever reason, > you're technically stalled on CPU in this moment. However, reclaim > itself consumes CPU and walltime, and it could be what is causing > those preemptions to begin with! For example, reclaim could eat up 90% > of your scheduling timeslice and then cause a preemption when the > thread is back in userspace and trying to be productive. By consuming > time, it also drags out the overall timeline for userspace to finish > its work, and a longer timeline will have more disruptions from > independent events like IRQs and RT thread wakeups. Reclaim could be running at RT priority. There is fundamentally no distinction between CFS and RT tasks. Consider priority inheritance on kernel mutexes, or an admin thinking it makes sense to chrt kswapd. Or an RT task ends up direct reclaim or... Either they all count or they don't. There is no sane middle ground here.
