Messages in this thread | | | Date | Wed, 21 Apr 2010 17:05:07 -0500 | From | Jack Steiner <> | Subject | Re: [Patch 1/1] init: Provide a kernel start parameter to increase pid_max v2 |
| |
On Wed, Apr 21, 2010 at 08:12:13PM +0100, Hedi Berriche wrote: > 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...)
> > [[ > > 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
| |