process view: hide kernel threads

[jelmd]

Usually kernel threads are just clutter in the process view: not much one can do about it, not of interest because resource usage is always 0 no matter, which one.

So it makes sense to hide them per default (and optionally add a CLI option or key binding to show them on demand).

To find out, whether a process is a kernel_thread, one may inspect field 9 (flags) of /proc/$pid/stat - if the values bit 0x00200000 is set, it is a kernel thread.

systemd-cgls e.g. does it this way: https://github.com/jelmd/cgls/blob/main/misc.c#L911

[brianc118]

I wonder if we should just add a boolean column to indicate if the process is a kernel process which can then be filtered normally. I think it'd still be better to keep them visible by default, but perhaps we can add support for hiding them via config.

[jelmd]

A boolean value is IMHO not useful, because the intention of the RFE is to reduce the view to the things one really wants to know, to make it more useful for day-by-day work by throwing away the clutter. Basically the "is_kernelthread" is already there: cgroup column. If cgroup == '/' it is a kernel thread - clutter ;-)

As said, I can't deduce anything useful from such rows except their names and whether they are idle|sleeping. Just paper weight which makes it much harder to spot the really interesting stuff. I guess for the same reason systemd-cgls authors decided to skip them by default, too.

[jelmd]

E.g. one an idle desktop box it means 270 rows less, on a file server 1398 rows less, on a multipurpose server 895 rows less. Measured with:

systemd-cgls -k |egrep '^├─ *[0-9]+ \['  |wc -l

[artificial-intelligence]

hard disagree on disabling kernel threads in the view per default.

it is actually valuable to detect that something is hogging up kernel threads.

but of course it should be possible to filter them out, I agree.

[jelmd]

That they might be useful in certain/rare corner cases does not mean, they are always useful. On the contrary (and as already said): Per default it is simply garbage a normal user does not need at all and make it very hard to identify real problem and thus make the tool useless! Therefore, hide per default and if there is someone, who actually understands, what the kernel threads are doing or even know, how to tackle related problems, he is probably smart enough to enable the thread view on demand ;-) .