On Thu, Sep 9, 2021 at 11:54 PM Johannes Weiner <hannes@xxxxxxxxxxx> wrote: > > On Thu, Sep 09, 2021 at 08:00:24PM +0800, Huangzhaoyang wrote: > > From: Zhaoyang Huang <zhaoyang.huang@xxxxxxxxxx> > > > > psi's memstall time is counted as simple as exit - entry so far, which ignore > > the task's off cpu time. Fix it by calc the percentage of off time via task and > > rq's util and runq load. > > > > Signed-off-by: Zhaoyang Huang <zhaoyang.huang@xxxxxxxxxx> > > Can you please explain what practical problem you are trying to solve? > > If a reclaimer gets preempted and has to wait for CPU, should that > stall be attributed to a lack of memory? Some of it should, since page > reclaim consumed CPU budget that would've otherwise been available for > doing real work. The application of course may still have experienced > a CPU wait outside of reclaim, but potentially a shorter one. Memory > pressure can definitely increase CPU pressure (as it can IO pressure). The preempted time which is mentioned here can be separated into 2 categories. First one is cfs task preempted because running out of the share of schedule_lantency. The second one is preempted by RT,DL and IRQs. IMO, the previous is reasonable to be counted in stall time, while the second one NOT. > > Proportional and transitive accounting - how much of total CPU load is > page reclaim, and thus how much of each runq wait is due to memory > pressure - would give more precise answers. But generally discounting > off-CPU time in a stall is not any more correct than including it all. > > This is doable, but I think there needs to be better justification for > providing this level of precision, since it comes with code complexity > that has performance and maintenance overhead. The rq's utilization of load tracking provides an easy way to compute such proportion. A new commit has been given out which mainly deals with the 2nd scenario described above. The statistics of the precision are provided together.
