Re: init's children list is long and slows reaping children.

Eric W. Biederman
2007-04-10T00:49:45Z

Andrew Morton <akpm@linux-foundation.org> writes:

> I suspect there are quite a few kernel threads which don't really need to
> be threads at all: the code would quite happily work if it was changed to
> use keventd, via schedule_work() and friends. But kernel threads are
> somewhat easier to code for.
>
> I also suspect that there are a number of workqueue threads which
> could/should have used create_singlethread_workqueue(). Often this is
> because the developer just didn't think to do it.
>
> otoh, a lot of these inefficeincies are probably down in scruffy drivers
> rather than in core or top-level code.
>
> <I also wonder where all these parented-by-init,
> presumably-not-using-kthread kernel threads are coming from>

>From another piece of this thread.

> > Robin how many kernel thread per cpu are you seeing?
>
> 10.
>
> FYI, pid 1539 is kthread.
>
> a01:~ # ps -ef | egrep "\[.*\/255\]"
> root 512 1 0 Apr08 ? 00:00:00 [migration/255]
> root 513 1 0 Apr08 ? 00:00:00 [ksoftirqd/255]
> root 1281 1 0 Apr08 ? 00:00:02 [events/255]
> root 2435 1539 0 Apr08 ? 00:00:00 [kblockd/255]
> root 3159 1539 0 Apr08 ? 00:00:00 [aio/255]
> root 4007 1539 0 Apr08 ? 00:00:00 [cqueue/255]
> root 8653 1539 0 Apr08 ? 00:00:00 [ata/255]
> root 17438 1539 0 Apr08 ? 00:00:00 [xfslogd/255]
> root 17950 1539 0 Apr08 ? 00:00:00 [xfsdatad/255]
> root 18426 1539 0 Apr08 ? 00:00:00 [rpciod/255]

So it looks like there were about 1500 kernel threads that started up before
kthread started.

So the kernel threads appear to have init as their parent is because
they started before kthread for the most part.

At 10 kernel threads per cpu there may be a little bloat but it isn't
out of control. It is mostly that we are observing the kernel as
NR_CPUS approaches infinity. 4096 isn't infinity yet but it's easily
a 1000 fold bigger then most people are used to :)

Eric