Messages in this thread | | | Date | Wed, 21 Apr 2010 20:12:13 +0100 | From | Hedi Berriche <> | Subject | Re: [Patch 1/1] init: Provide a kernel start parameter to increase pid_max v2 |
| |
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
| |