Hello, On Thu, Nov 07, 2024 at 07:05:46PM +0100, Michal Koutný wrote: ... > I'd first ask why the kvm_vm_worker_thread needs to be in the KVM task's > cgroup (and copy its priority at creation time but no later adjustments)? > > If it can remain inside root cgroup (like any other good kthread) its > job may be even chunked into periodic/deferred workqueue pieces with no > kthread per KVM at all. That'd be better but I suppose kvm wants them in the same cgroup for a reason. > If there are resource control/charging concerns, I was thinking about > the approach of cloning from the KVM task and never returning to > userspace, which I see you already discussed with PF_USER_WORKER (based > on #1). All context would be regularly inherited and no migration would > be needed. > > (I remember issues with the kvm_vm_worker_thread surviving lifespan of > KVM task and preventing removal of the cgroup. Not sure if that was only > a race or there's real need for doing some cleanups on an exited task.) > > As for #2, I'm not sure there's a good criterion for what to ignore. > Here it could possibly be PF_KTHREAD or PF_NOFREEZE (I get the latter > has purpose for system-wide (or v1) freezer). Generally, we can't tell > what's the effect of thread's liveliness so it seems better to > conservatively treat the cgroup as unfrozen. It'd have to be a separate flag which explicitly says that the task is exempt from cgroup2 freezer, so yeah, it'd be best if we can avoid this option. Thanks. -- tejun
