Prev: Compile error with 2.6.34-rc5+
Next: [PATCH -v2 0/5] AMD L3 cache index disable fixes for .35
From: Robin Holt on 22 Apr 2010 10:00
> 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.

I don't understand how it would be possible for the arch maintainers
to predict what a particular machine's configuration would need for
PIDS_PER_CPU. Many of the extra pids needed on a per-cpu basis are
brought in by device drivers or subsystems.

Are you proposing a typical configuration be used for the basis or an
extreme configuration?

If your basis is the typical configuration, how would an administrator
of the extreme configuration get themselves out of the situation of
pids_max being too small without the same command line option.

If we use the extreme case, then we end up with a lot of extraneous pids,
however I don't see that as being too terrible of a situation.

Robin
--
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: Linus Torvalds on 22 Apr 2010 11:00


On Thu, 22 Apr 2010, Alan Cox wrote:
>
> > 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 ?

Ehh. Nobody does ia64 any more. It's dead, Jim.

This is x86. SGI finally long ago gave up on the Intel/HP clusterf*ck.

Which I'm not entirely sure makes the case for the kernel parameter much
stronger, though. I wonder if it's not more appropriate to just have a
total hack saying

if (max_pids < N * max_cpus) {
printk("We have %d CPUs, increasing max_pids to %d\n");
max_pids = N*max_cpus;
}

where "N" is just some random fudge-factor. It's reasonable to expect a
certain minimum number of processes per CPU, after all.

Linus
--
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: Robin Holt on 22 Apr 2010 13:10
> Which I'm not entirely sure makes the case for the kernel parameter much
> stronger, though. I wonder if it's not more appropriate to just have a
> total hack saying
>
> if (max_pids < N * max_cpus) {
> printk("We have %d CPUs, increasing max_pids to %d\n");
> max_pids = N*max_cpus;
> }
>
> where "N" is just some random fudge-factor. It's reasonable to expect a
> certain minimum number of processes per CPU, after all.

How about:

pid_max_min = max(pid_max_min, 19 * num_possible_cpus());
pid_max_baseline = 2048 * num_possible_cpus();

if (pid_max < pid_max_baseline) {
printk("We have %d CPUs, increasing pid_max to %d\n"...
pid_max = pid_max_baseline;
}


This would scale pid_max_min by a sane amount, leave the default value
of pid_max_min and pid_max untouched below 16 cpus and then scale both
up linearly beyond that.

Robin
--
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: John Stoffel on 22 Apr 2010 14:20
>>>>> "Robin" == Robin Holt <holt(a)sgi.com> writes:

>> Which I'm not entirely sure makes the case for the kernel parameter much
>> stronger, though. I wonder if it's not more appropriate to just have a
>> total hack saying
>>
>> if (max_pids < N * max_cpus) {
>> printk("We have %d CPUs, increasing max_pids to %d\n");
>> max_pids = N*max_cpus;
>> }
>>
>> where "N" is just some random fudge-factor. It's reasonable to expect a
>> certain minimum number of processes per CPU, after all.

Robin> How about:

Robin> pid_max_min = max(pid_max_min, 19 * num_possible_cpus());
Robin> pid_max_baseline = 2048 * num_possible_cpus();

Robin> if (pid_max < pid_max_baseline) {
Robin> printk("We have %d CPUs, increasing pid_max to %d\n"...
Robin> pid_max = pid_max_baseline;
Robin> }


Robin> This would scale pid_max_min by a sane amount, leave the default value
Robin> of pid_max_min and pid_max untouched below 16 cpus and then scale both
Robin> up linearly beyond that.

Looks good, but how about some comments and some defines for the magic
numbers of 2048 and 19?

John

--
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: Andrew Morton on 22 Apr 2010 16:40
On Thu, 22 Apr 2010 12:08:02 -0500
Robin Holt <holt(a)sgi.com> wrote:

> > Which I'm not entirely sure makes the case for the kernel parameter much
> > stronger, though. I wonder if it's not more appropriate to just have a
> > total hack saying
> >
> > if (max_pids < N * max_cpus) {
> > printk("We have %d CPUs, increasing max_pids to %d\n");
> > max_pids = N*max_cpus;
> > }
> >
> > where "N" is just some random fudge-factor. It's reasonable to expect a
> > certain minimum number of processes per CPU, after all.
>
> How about:
>
> pid_max_min = max(pid_max_min, 19 * num_possible_cpus());
> pid_max_baseline = 2048 * num_possible_cpus();
>
> if (pid_max < pid_max_baseline) {
> printk("We have %d CPUs, increasing pid_max to %d\n"...
> pid_max = pid_max_baseline;
> }
>
>
> This would scale pid_max_min by a sane amount, leave the default value
> of pid_max_min and pid_max untouched below 16 cpus and then scale both
> up linearly beyond that.

Something like that would work. We shouild ensure that pid_max cannot
end up being less than the current PID_MAX_DEFAULT.

--
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/
 |  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