Prev: Compile error with 2.6.34-rc5+
Next: [PATCH -v2 0/5] AMD L3 cache index disable fixes for .35
From: Alan Cox on 22 Apr 2010 05:30
> Distros don't want to take a patch that adds a new boot param that is
> not accepted upstream, otherwise they will be stuck forward porting it
> from now until, well, forever :)

So for an obscure IA64 specific problem you want the upstream kernel to
port it forward forever instead ?
>
> As this solves a problem that people are having today, on the kernel.org
> kernel, on a known machine, and we really don't know when the "reduce
> the number of processes per cpu" work will be done, or if it really will
> solve this issue, then why can't we take it now? If the work does solve
> the problem in the future, then we can take the command line option out,
> and everyone is happy.
>
> Sound reasonable?

No - to start with it would be far saner for everything involved if the
4096 processor minority fixed it for the moment in their arch code by
doing something like

if (max_pids < PIDS_PER_CPU * num_cpus) {
max_pids = ...
printk(something informative)
}

in their __init marked code.

Because when Tejun's stuff is in the patch can go away, and also if it's
not sufficient then the patch above should keep it sane when they go to
32000 cpus or whatever is next.

Alan
--
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: Alan Cox on 21 Apr 2010 05:30
> of 32k will not be enough. A system with 1664 CPU's, there are 25163 processes
> started before the login prompt. It's estimated that with 2048 CPU's we will pass

Is that perhaps the bug not the 32K limit ? and does Tejun's work on work
queue sanity help avoid the need for this ?
--
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: Rik van Riel on 21 Apr 2010 13:20
On 04/21/2010 12:59 PM, Hedi Berriche wrote:
> On Wed, Apr 21, 2010 at 10:20 Alan Cox wrote:
> |> of 32k will not be enough. A system with 1664 CPU's, there are 25163 processes
> |> started before the login prompt. It's estimated that with 2048 CPU's we will pass
> |
> | Is that perhaps the bug not the 32K limit?
>
> Doubt it: I just checked on an *idle* 1664 CPUs system and I can see 26844
> tasks, all but few being kernel threads.

That is 15 kernel threads per CPU.

Reducing the number of kernel threads sounds like a
useful thing to do.
--
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: Mike Travis on 21 Apr 2010 14:00


Rik van Riel wrote:
> On 04/21/2010 12:59 PM, Hedi Berriche wrote:
>> On Wed, Apr 21, 2010 at 10:20 Alan Cox wrote:
>> |> of 32k will not be enough. A system with 1664 CPU's, there are
>> 25163 processes
>> |> started before the login prompt. It's estimated that with 2048
>> CPU's we will pass
>> |
>> | Is that perhaps the bug not the 32K limit?
>>
>> Doubt it: I just checked on an *idle* 1664 CPUs system and I can see
>> 26844
>> tasks, all but few being kernel threads.
>
> That is 15 kernel threads per CPU.
>
> Reducing the number of kernel threads sounds like a
> useful thing to do.

I'm doing more research but all the udev modprobes seem to spawn
quite a few tasks. And even though they go away, when the pid
pool is limited, I'm guessing many of them are waiting.

On the last test I did yesterday, the pid # was up in the 77000
range at the login prompt (I started the 1664 cpu system with
pid_max=128k).
--
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: Alan Cox on 21 Apr 2010 14:00
On Wed, 21 Apr 2010 17:59:34 +0100
Hedi Berriche <hedi(a)sgi.com> wrote:

> On Wed, Apr 21, 2010 at 10:20 Alan Cox wrote:
> | > of 32k will not be enough. A system with 1664 CPU's, there are 25163 processes
> | > started before the login prompt. It's estimated that with 2048 CPU's we will pass
> |
> | Is that perhaps the bug not the 32K limit?
>
> Doubt it: 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.

And as I asked before - how does Tejun's work on sanitizing work queues
affect this ?

Alan
--
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  |  Next  |  Last
Pages: 1 2 3 4
Prev: Compile error with 2.6.34-rc5+
Next: [PATCH -v2 0/5] AMD L3 cache index disable fixes for .35