On Wed, Apr 21, 2010 at 08:12:13PM +0100, Hedi Berriche wrote:
quoted text
> On Wed, Apr 21, 2010 at 18:54 Alan Cox wrote:
> | Hedi Berriche <hedi@sgi.com> wrote:
> |
> | > I just checked on an *idle* 1664 CPUs system and I can see 26844 tasks, all
> | > but few being kernel threads.
> | 
> | So why have we got 26844 tasks. Isn't that a rather more relevant
> | question.
> 
> OK, here's a rough breakdown of the tasks
> 
>      104 kswapd
>     1664 aio
>     1664 ata
>     1664 crypto
>     1664 events
>     1664 ib_cm
>     1664 kintegrityd
>     1664 kondemand
>     1664 ksoftirqd
>     1664 kstop
>     1664 migration
>     1664 rpciod
>     1664 scsi_tgtd
>     1664 xfsconvertd
>     1664 xfsdatad
>     1664 xfslogd
> 
> that's 25064, omitting the rest as its contribution to the overall total is
> negligible.

Also, our target for the number of cpus is 4096. We are not even halfway there.
(I certainly expect other issues to arise scaling to 4096p but running out of pids
_should_ not be one of them...)



quoted text
> 
> [[
> 
> Let's also not forget all those ephemeral user space tasks (udev and the likes)
> that will be spawned at boot time on even large systems with even more
> thousands of disks, arguably one might consider hack initrd and similar to work
> around the problem and set pid_max as soon as /proc becomes available but it's
> a bit of a PITA.
> 
> ]]
> 
> | And as I asked before - how does Tejun's work on sanitizing work queues
> | affect this ?
> 
> I'm not familiar with the work in question so I (we) will have to look it up,
> and at it and see whether it's relevant to what we're seeing here. It does sound
> like it might help, to certain extent at least.
> 
> That said, while I am genuinely interested in spending time on this and digging
> further to see whether something has/can be done about keeping under control the
> number of tasks required to comfortably boot a system of this size, I think that
> in the meantime the boot parameter approach is useful in the sense that it addresses
> the immediate problem of being able such systems *without* any risk to break the
> code or alter the default behaviour.
> 
> Cheers,
> Hedi.
> -- 
> Be careful of reading health books, you might die of a misprint.
> 	-- Mark Twain
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/