On Mon, Apr 09, 2007 at 06:48:54PM -0600, Eric W. Biederman wrote: > Andrew Morton <[EMAIL PROTECTED]> 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.
I should have been more clear, this is from that 4096 broken down to a 512 cpu partition. This is the configuration the customer will receive the machine. The 4096 was just to see if it worked. > 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 - 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/
