On Wednesday, 11 April 2007 09:03, Andrew Morton wrote: > On Tue, 10 Apr 2007 23:44:36 -0600 [EMAIL PROTECTED] (Eric W. Biederman) > wrote: > > > Currently there is a circular reference between work queue initialization > > and kthread initialization. This prevents the kernel thread > > infrastructure from initializing until after work queues have been > > initialized. > > > > For kernel threads we want something that is as close as possible to the > > init_task and is not contaminated by user processes. The later we start > > our kthreadd that forks the rest of the kernel threads the harder this is > > to do and the more of a mess we have to clean up because the defaults have > > changed on us. > > > > So this patch modifies the kthread support to not use work queues but to > > instead use a simple list of structures, and to have kthreadd start from > > init_task immediately after our kernel thread that execs /sbin/init. > > > > By being a true child of init_task we only have to change those process > > settings that we want to have different from init_task, such as our > > process name, blocking all signals and setting SIGCHLD to SIG_IGN > > so that all of our children are reaped automatically. > > > > By being a tre child of init_task we also naturally get our ppid set to 0 > > and do not wind up as a child of PID == 1. Ensuring that kernel threads > > will not slow down the functioning of the wait family of functions. > > argh. Your description freely confuddles the terms "kernel thread" and > "kthread". Can we not do that? Henceforth the term "kernel thread" refers > to something which was started with kernel_thread() and "kthread" refers to > something which was created by kthread_create(), OK? > > Your patch gets midly tangled up with Oleg's recent > > reduce-reparent_to_init.patch > make-kernel-threads-invisible-to-sbin-init.patch > reparent-kernel-threads-to-swapper.patch > > but they seemed fairly unpopular anyway so I'll drop 'em. > > Your wait_event() will contribute to load average, I expect. We get mail. > I converted it to wait_event_interruptible(). > > I guess using PF_NOFREEZE rather than try_to_freeze() is OK, but one > wonders what thinking led to that?
It should be calling try_to_freeze() somewhere anyway. We may need to freeze all tasks in some cases. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
