Peter Zijlstra <peterz@xxxxxxxxxxxxx> writes: > On Thu, Apr 16, 2020 at 09:24:35AM +0800, Huang, Ying wrote: >> Peter Zijlstra <peterz@xxxxxxxxxxxxx> writes: >> >> > On Tue, Apr 14, 2020 at 01:06:46PM +0100, Mel Gorman wrote: >> >> While it's just an opinion, my preference would be to focus on reducing >> >> the cost and amount of scanning done -- particularly for threads. >> > >> > This; I really don't believe in those back-charging things, esp. since >> > not having cgroups or having multiple applications in a single cgroup is >> > a valid setup. >> >> Technically, it appears possible to back-charge the CPU time to the >> process/thread directly (not the cgroup). > > I've yet to see a sane proposal there. What we're not going to do is > make regular task accounting more expensive than it already is. Yes. There's overhead to back-charge. To reduce the overhead, instead of back-charge immediately, we can - Add one field to task_struct, say backcharge_time, to track the delayed back-charged CPU time. - When the work item completes its work, add the CPU time it spends to task_struct->backcharge_time atomically - When the task account CPU regularly, e.g. in scheduler_tick(), task_struct->backcharge is considered too. Although this cannot eliminate the overhead, it can reduce it. Do you think this is acceptable or not? Best Regards, Huang, Ying
