On Mon, Oct 28, 2024 at 02:07:36PM GMT, Tejun Heo <tj@xxxxxxxxxx> wrote: > There are two paths that we can take: > > 1. Make kvm_vm_worker_thread() call into signal delivery path. > io_wq_worker() is in a similar boat and handles signal delivery and can > be frozen and trapped like regular threads. > > 2. Keep the count of threads which can't be frozen per cgroup so that cgroup > freezer can ignore these threads. > > #1 is better in that the cgroup will actually be frozen when reported > frozen. However, the rather ambiguous criterion we've been using for cgroup > freezer is whether the cgroup can be safely snapshotted whil frozen and as > long as the workers not being frozen doesn't break that, we can go for #2 > too. > > What do you guys think? 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. 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. HTH, Michal
Attachment:
signature.asc
Description: PGP signature
