Prev: Compile error with 2.6.34-rc5+
Next: [PATCH -v2 0/5] AMD L3 cache index disable fixes for .35
From: John Stoffel on 21 Apr 2010 15:40
>>>>> "Rik" == Rik van Riel <riel(a)redhat.com> writes:

Rik> 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.

Rik> That is 15 kernel threads per CPU.

Rik> Reducing the number of kernel threads sounds like a
Rik> useful thing to do.

Isn't that already a project? I thought someone (Jeff? Jorn? Tejun? Bueller
bueller....?) was already proposing a patch set to reduce the number
of kernel threads by having dynamic workqueues instead, so that we
didn't spawn a bunch of threads that never did anything?

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: Greg KH on 21 Apr 2010 16:00
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.

thanks,

greg k-h
--
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: Greg KH on 21 Apr 2010 18:40
On Wed, Apr 21, 2010 at 04:10:08PM -0400, John Stoffel wrote:
> >>>>> "Hedi" == Hedi Berriche <hedi(a)sgi.com> writes:
>
> Hedi> On Wed, Apr 21, 2010 at 20:15 John Stoffel wrote:
> Hedi> | >>>>> "Rik" == Rik van Riel <riel(a)redhat.com> writes:
> Hedi> |
> Hedi> | Rik> That is 15 kernel threads per CPU.
> Hedi> |
> Hedi> | Rik> Reducing the number of kernel threads sounds like a
> Hedi> | Rik> useful thing to do.
> Hedi> |
> Hedi> | Isn't that already a project?
>
> Hedi> Yes, thanks to Alan's probing I looked it up
>
> Hedi> http://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git
>
> Hedi> but we're definitely talking long term solution vs. something
> Hedi> that can ease pain now.
>
> It seems to me that running Linux on such a large machine is such a
> specialized niche, the putting in your change to the regular kernel
> isn't a near term need either. And from the sounds of it, Tejun's
> work has better long term potential.

Tejun's work has much better long term potential, but this is still an
issue for large #cpu systems, which we want Linux to support well. This
isn't a "specialized niche" for Linux, at all, Linux pretty much
dominates this hardware area, and it would be nice to ensure that this
continues.

thanks,

greg k-h
--
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 19:00
On 04/21/2010 06:24 PM, Greg KH wrote:

> Tejun's work has much better long term potential, but this is still an
> issue for large #cpu systems, which we want Linux to support well. This
> isn't a "specialized niche" for Linux, at all, Linux pretty much
> dominates this hardware area, and it would be nice to ensure that this
> continues.

Yes, the pid_max patch seems like a decent stop gap for
distro kernels right now. However, Tejun's work is
probably a more appropriate path forward.
--
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: Greg KH on 21 Apr 2010 19:50
On Wed, Apr 21, 2010 at 06:49:22PM -0400, Rik van Riel wrote:
> On 04/21/2010 06:24 PM, Greg KH wrote:
>
> >Tejun's work has much better long term potential, but this is still an
> >issue for large #cpu systems, which we want Linux to support well. This
> >isn't a "specialized niche" for Linux, at all, Linux pretty much
> >dominates this hardware area, and it would be nice to ensure that this
> >continues.
>
> Yes, the pid_max patch seems like a decent stop gap for
> distro kernels right now. However, Tejun's work is
> probably a more appropriate path forward.

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 :)

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?

thanks,

greg k-h
--
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