Re: [Patch 1/1] init: Provide a kernel start parameter to increase pid_max v2

[Hedi Berriche <hedi@sgi.com>]

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.

[[

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