On Tue, Jun 11, 2019 at 12:55:49PM -0700, Tejun Heo wrote: > > > CPU doesn't have a backcharging mechanism yet and depending on the use > > > case, we *might* need to put kthreads in different cgroups. However, > > > such use cases might not be that abundant and there may be gotaches > > > which require them to be force-executed and back-charged (e.g. fs > > > compression from global reclaim). > > > > The CPU-intensiveness of these works is one of the reasons for actually putting > > the workers through the migration path. I don't know of a way to get the > > workers to respect the cpu controller (and even cpuset for that matter) without > > doing that. > > So, I still think it'd likely be better to go back-charging route than > actually putting kworkers in non-root cgroups. That's gonna be way > cheaper, simpler and makes avoiding inadvertent priority inversions > trivial. Ok, I'll experiment with backcharging in the cpu controller. Initial plan is to smooth out resource usage by backcharging after each chunk of work that each helper thread does rather than do one giant backcharge after the multithreaded job is over. May turn out better performance-wise to do it less often than this. I'll also experiment with getting workqueue workers to respect cpuset without migrating. Seems to make sense to use the intersection of an unbound worker's cpumask and the cpuset's cpumask, and make some compromises if the result is empty. Daniel
