Robin Holt writes:
> On Mon, Apr 09, 2007 at 08:36:21AM -0600, Eric W. Biederman wrote:
>> Robin Holt <[email protected]> writes:
>>> I would say this is more a benefit than a problem. With a couple
>>> of these systems we are testing, the number of kernel threads is
>>> far greater than the number of user processes and having pstree
>>> not normally show them, but maybe have an option we add later to
>>> show them again would be beneficial.
>>
>> Sure.
>>
>> Robin how many kernel thread per cpu are you seeing?
>
> 10.
This has long been rotten. Mind fixing it for us? :-)
We have N types of thread on M CPUs. Pick something, N or M,
to be at the top level in /proc. The other goes below, in the
per-process task directories.
You then have either N or M things showing up in ps, not N*M.
Note that both ps and top can print the CPU number just fine.
Abusing the task name for this is just retarded. This suggests
that the top level should be the type of task, with the lower
level in /proc/*/task being per-CPU and not needing distinct
naming at all.
"Albert Cahalan" <[email protected]> writes:
> This has long been rotten. Mind fixing it for us? :-)
>
> We have N types of thread on M CPUs. Pick something, N or M,
> to be at the top level in /proc. The other goes below, in the
> per-process task directories.
>
> You then have either N or M things showing up in ps, not N*M.
>
> Note that both ps and top can print the CPU number just fine.
> Abusing the task name for this is just retarded. This suggests
> that the top level should be the type of task, with the lower
> level in /proc/*/task being per-CPU and not needing distinct
> naming at all.
In a lot of ways that is reasonable. However kernel threads don't
share signal handling and getting to the point where they could share
signal handling would be difficult so we cannot use the generic
CLONE_THREAD handling they really are more like individual processes.
So at that level the cpu number in the name is just to help tell them
apart.
Eric