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

[Eric W. Biederman]

Oleg Nesterov <oleg@xxxxxxxxxx> writes:

>> At first glance your patch looks reasonable.
>> 
>> Unfortunately it only applies to the rare thread that calls daemonize,
>> and not also to kernel/kthread/kthread() which means it will miss many of
>> our current kernel threads.
>
> Note that a thread created by kthread_create() has ->parent == "[kthread]",
> not /sbin/init (unless it was created before core_initcall). So I don't really
> understand how stop_machine() creates the threads parented to init.

Duh.  I was looking for that detail but the code was sufficiently
abstracted that I missed it skimming through.  Now I see it thanks.
That at least explains how a handful of threads created with
kthread_create have init as their parent.

My gut feel says it makes sense to change reparent_to_init to 
reparent_to_kthread.  Which will get the all of the kernel daemons
under a single parent.  Further I think it makes sense to see if
we can start kthread earlier. Having kthread have pid == 2 would be
nice.  That way we can kill the conditional that is only used during
early initialization (make the code simpler and more predictable).

Since we seem to need kthread for the work of forking kernel threads,
I don't see much point in not having a proper process tree, and a
single extra child for pid == 1 isn't going to hurt anyone.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/