On Tue, Oct 05, 2021 at 07:15:43PM +0200, Paolo Bonzini wrote: > On 05/10/21 15:21, Marcelo Tosatti wrote: > > > The QEMU I/O thread is not hogging the CPU 100% of the time, and > > > therefore the nx-recovery thread should be able to run on that CPU. > > > > 1) The cpumask of the parent thread is not inherited > > > > set_cpus_allowed_ptr(task, housekeeping_cpumask(HK_FLAG_KTHREAD)); > > > > On __kthread_create_on_node should fail (because its cgroup, the one > > inherited from QEMU, contains only isolated CPUs). > > > > (The QEMU I/O thread runs on an isolated CPU, and is moved by libvirt > > to HK-cgroup as mentioned before). > > Ok, that's the part that I missed. So the core issue is that libvirt moves > the I/O thread out of the isolated-CPU cgroup too late? This in turn is > because libvirt gets access to the QEMU monitor too late (the KVM file > descriptor is created when QEMU processes the command line). Actually, what i wrote was incorrect: set_cpus_allowed_ptr should succeed (kthread creation), but cgroup_attach_task_all will override the kthread mask with the cgroup mask (which contains isolated CPUs). Paolo: about your suggestion to use the same CPU for nx-recovery thread as the I/O thread one: I believe the cpumask of the userspace parent (QEMU I/O thread) is not inherited by the kernel thread. We will resend the patchset once more data to justify this is available (or will if an userspace solution is not possible).
