Prev: kvm vmx: free vpid when fail to create vcpu
Next: HSI: Introducing HSI framework
From: Hedi Berriche on 21 Apr 2010 16:20
On Wed, Apr 21, 2010 at 20:52 Greg KH wrote:
| On Wed, Apr 21, 2010 at 08:12:13PM +0100, Hedi Berriche wrote:
| > 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.
|
| udev should properly handle large numbers of cpus and the tasks that it
| spawns so as to not overload things. If not, and you feel it is
| creating too many tasks, please let the udev developers know and they
| will be glad to work with you on this issue.

Just to be clear here --and be done with the udev parenthesis-- we kind of need
udev to take advantage of the fact that there's a large number of CPUs on the
machine especially on in the case of a config with thousands of disks, as that
shortens the time required to have a box in a working state with all disks
available and all.

IOW, I am not after throttling or serialising udev, just mentioned it as an
example of user space beast that can contribute --in the current state of things--
to the need of having a large number of pid_max on certain configurations.

That said I do realise that bit too should be looked at and any problems, as you
quite rightly pointed out, should be discussed with the udev chaps.

Cheers,
Hedi.
--
Be careful of reading health books, you might die of a misprint.
-- Mark Twain
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Jack Steiner on 21 Apr 2010 18:10
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(a)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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  | 
Pages: 1 2
Prev: kvm vmx: free vpid when fail to create vcpu
Next: HSI: Introducing HSI framework