On Mon, Jan 27, 2025 at 3:10 PM Oleg Nesterov <oleg@xxxxxxxxxx> wrote: > On 01/26, Linus Torvalds wrote: > > On Sun, 26 Jan 2025 at 10:54, Oleg Nesterov <oleg@xxxxxxxxxx> wrote: > > > > > > I don't think we even need to detect the /proc/self/ or /proc/self-thread/ > > > case, next_tid() can just check same_thread_group, > > > > That was my thinking yes. > > > > If we exclude them from /proc/*/task entirely, I'd worry that it would > > hide it from some management tool and be used for nefarious purposes > > Agreed, > > > (even if they then show up elsewhere that the tool wouldn't look at). > > Even if we move them from /proc/*/task to /proc ? Indeed---as long as they show up somewhere, it's not worse than it used to be. The reason why I'd prefer them to stay in /proc/*/task is that moving them away at least partly negates the benefits of the "workers are children of the starter" model. For example it complicates measuring their cost within the process that runs the VM. Maybe it's more of a romantic thing than a real practical issue, because in the real world resource accounting for VMs is done via cgroups. But unlike the lazy creation in KVM, which is overall pretty self-contained, I am afraid the ugliness in procfs would be much worse compared to the benefit, if there's a benefit at all. > Perhaps, I honestly do not know what will/can confuse userspace more. At the very least, marking workers as "Kthread: 1" makes sense and should not cause too much confusion. I wouldn't go beyond that unless we get more reports of similar issues, and I'm not even sure how common it is for userspace libraries to check for single-threadedness. Paolo > > But as mentioned, maybe this is all more of a hack than what kvm now does. > > I don't know. But I will be happy to make a patch if we have a consensus. > > Oleg. >
