public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: ebiederm@xmission.com (Eric W. Biederman)
Cc: Jeff Garzik <jeff@garzik.org>, Robin Holt <holt@sgi.com>,
	Ingo Molnar <mingo@elte.hu>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	Jack Steiner <steiner@americas.sgi.com>
Subject: Re: init's children list is long and slows reaping children.
Date: Mon, 9 Apr 2007 18:15:40 -0700	[thread overview]
Message-ID: <20070409181540.579e55d4.akpm@linux-foundation.org> (raw)
In-Reply-To: <m1mz1hyryh.fsf@ebiederm.dsl.xmission.com>

On Mon, 09 Apr 2007 18:48:54 -0600
ebiederm@xmission.com (Eric W. Biederman) wrote:

> 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.

Yeah, sorry.  Without mentioning any names, someone@tv-sign.ru broke the
threading so I came in halfway.

> > > 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 :)

Yes, I expect we could run init_workqueues() much earlier, from process 0
rather than from process 1.  Something _might_ blow up as it often does when
we change startup ordering, but in this case it would be somewhat surprising.


  reply	other threads:[~2007-04-10  1:15 UTC|newest]

Thread overview: 112+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-05 19:51 init's children list is long and slows reaping children Robin Holt
2007-04-05 20:57 ` Linus Torvalds
2007-04-06  0:51   ` Chris Snook
2007-04-06  1:03     ` Chris Snook
2007-04-06  1:29     ` Linus Torvalds
2007-04-06  2:15       ` Eric W. Biederman
2007-04-06 10:43         ` Robin Holt
2007-04-06 15:38           ` Eric W. Biederman
2007-04-06 16:31             ` Oleg Nesterov
2007-04-06 17:32               ` Ingo Molnar
2007-04-06 17:39                 ` Roland Dreier
2007-04-06 18:04                   ` Eric W. Biederman
2007-04-06 18:30                 ` Eric W. Biederman
2007-04-06 19:18                   ` [patch] sched: get rid of p->children use in show_task() Ingo Molnar
2007-04-06 19:22                     ` Ingo Molnar
2007-04-10 13:48                   ` init's children list is long and slows reaping children Ingo Molnar
2007-04-10 13:38                     ` Oleg Nesterov
2007-04-10 15:00                       ` Eric W. Biederman
2007-04-10 15:16                       ` [PATCH] Only send pdeath_signal when getppid changes Eric W. Biederman
2007-04-10 16:37                         ` Oleg Nesterov
2007-04-10 17:41                           ` Eric W. Biederman
2007-04-10 17:48                             ` Roland McGrath
2007-04-11  3:17                               ` Albert Cahalan
2007-04-10 14:51                     ` init's children list is long and slows reaping children Eric W. Biederman
2007-04-10 15:06                       ` Ingo Molnar
2007-04-10 15:22                         ` Eric W. Biederman
2007-04-10 15:53                           ` Ingo Molnar
2007-04-10 16:17                             ` Eric W. Biederman
2007-04-11  6:20                             ` [patch] uninline remove/add_parent() APIs Ingo Molnar
2007-04-11  7:00                               ` Eric W. Biederman
2007-04-11 22:06                                 ` Andrew Morton
2007-04-12 10:45                                   ` Eric W. Biederman
2007-04-12 22:50                                   ` Roland McGrath
2007-04-10 16:44                       ` init's children list is long and slows reaping children Oleg Nesterov
2007-04-11 19:55                         ` Bill Davidsen
2007-04-11 20:17                           ` Eric W. Biederman
2007-04-11 21:24                             ` Bill Davidsen
2007-04-11 20:19                           ` Oleg Nesterov
2007-04-06 18:02               ` Eric W. Biederman
2007-04-06 18:21               ` Davide Libenzi
2007-04-06 18:56                 ` Eric W. Biederman
2007-04-06 19:16                   ` Davide Libenzi
2007-04-06 19:19                     ` Ingo Molnar
2007-04-06 21:29                       ` Davide Libenzi
2007-04-06 21:51                         ` Linus Torvalds
2007-04-06 22:31                           ` Davide Libenzi
2007-04-06 22:46                             ` Linus Torvalds
2007-04-06 22:59                               ` Davide Libenzi
2007-04-09  8:28                           ` Ingo Molnar
2007-04-09 18:09                             ` Bill Davidsen
2007-04-09 19:28                               ` Kyle Moffett
2007-04-09 19:51                                 ` Linus Torvalds
2007-04-09 20:03                                   ` Davide Libenzi
2007-04-10 15:12                                     ` Bill Davidsen
2007-04-10 19:17                                       ` Davide Libenzi
2007-04-09 20:00                                 ` Eric W. Biederman
2007-04-06 16:41             ` Robin Holt
2007-04-09 17:37         ` Chris Snook
2007-04-06 18:05       ` Christoph Hellwig
2007-04-06 19:39         ` Eric W. Biederman
2007-04-06 22:38 ` Jeff Garzik
2007-04-06 22:51   ` Linus Torvalds
2007-04-06 23:37     ` Jeff Garzik
2007-04-11  7:28       ` Nick Piggin
2007-04-10  0:23   ` Andrew Morton
2007-04-10  0:48     ` Eric W. Biederman
2007-04-10  1:15       ` Andrew Morton [this message]
2007-04-10  6:53       ` Jeff Garzik
2007-04-10  9:42       ` Robin Holt
2007-04-10  1:59     ` Dave Jones
2007-04-10  2:30       ` Andrew Morton
2007-04-10  2:46         ` Linus Torvalds
2007-04-10  7:07           ` Jeff Garzik
2007-04-10 22:20             ` Ingo Oeser
2007-04-10  5:07         ` Alexey Dobriyan
2007-04-10  5:21           ` Dave Jones
2007-04-10  6:09         ` Torsten Kaiser
2007-04-10  7:08           ` Jeff Garzik
2007-04-10  7:05         ` Jeff Garzik
2007-04-10  7:37           ` Andrew Morton
2007-04-10  8:33             ` Jeff Garzik
2007-04-10  8:41               ` Andrew Morton
2007-04-10  8:48                 ` Jeff Garzik
2007-04-10 22:35                   ` Ingo Oeser
2007-04-10 16:35           ` Matt Mackall
2007-04-10  7:44         ` Russell King
2007-04-10  8:16           ` Jeff Garzik
2007-04-10  8:59           ` Ingo Molnar
2007-04-10  9:33             ` Jeff Garzik
  -- strict thread matches above, loose matches on Subject: below --
2007-04-06  8:42 Oleg Nesterov
2007-04-06  9:10 ` Eric W. Biederman
2007-04-06  9:44   ` Oleg Nesterov
2007-04-06 15:45     ` Eric W. Biederman
2007-04-06 15:47       ` Oleg Nesterov
2007-04-06 17:16         ` Linus Torvalds
2007-04-06 17:27           ` Ingo Molnar
2007-04-06 17:31             ` Ingo Molnar
2007-04-06 17:34           ` Eric W. Biederman
2007-04-06 19:06             ` H. Peter Anvin
2007-04-06 19:15               ` Eric W. Biederman
2007-04-06 19:21                 ` H. Peter Anvin
2007-04-06 21:04                 ` Jeremy Fitzhardinge
2007-04-06 21:07                   ` H. Peter Anvin
2007-04-06 19:36           ` Oleg Nesterov
2007-04-06 19:43             ` Ingo Molnar
2007-04-06 20:01               ` Oleg Nesterov
2007-04-06 20:21                 ` Ingo Molnar
2007-04-06 19:47             ` Oleg Nesterov
2007-04-06 19:59               ` Eric W. Biederman
2007-04-07 20:31             ` Oleg Nesterov
2007-04-08  0:38               ` Eric W. Biederman
2007-04-08 15:46                 ` Oleg Nesterov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070409181540.579e55d4.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=holt@sgi.com \
    --cc=jeff@garzik.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=steiner@americas.sgi.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox