lkml.org 
[lkml]   [2010]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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


    \
     
     \ /
      Last update: 2010-04-22 00:07    [W:5.504 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site