Frans Pop wrote:
> [EMAIL PROTECTED] wrote:
>>8472457 Total 30486950 +259% 30342823 +258%
>
> Hmmm. The table for previous versions looked a lot more impressive.
>
> now:8472457 Total +22014493 +259% +21870366 +258%
> V2 :7172678 Total+23314404 +325%
On Wed, 16 Jan 2008, Nick Piggin wrote:
> Oh, just while I remember it also, something funny is that MAX_NUMNODES
> can be bigger than NR_CPUS on x86. I guess one can have CPUless nodes,
> but wouldn't it make sense to have an upper bound of NR_CPUS by default?
There are special configurations
[EMAIL PROTECTED] wrote:
>8472457 Total 30486950 +259% 30342823 +258%
Hmmm. The table for previous versions looked a lot more impressive.
now:8472457 Total+22014493 +259% +21870366 +258%
V2 :7172678 Total+23314404 +325% -147590 -2%
This patchset addresses the kernel bloat that occurs when NR_CPUS is increased.
The memory numbers below are with NR_CPUS = 1024 which I've been testing (4 and
32 real processors, the rest "possible" using the additional_cpus start option.)
These changes are all specific to the x86 architecture,
This patchset addresses the kernel bloat that occurs when NR_CPUS is increased.
The memory numbers below are with NR_CPUS = 1024 which I've been testing (4 and
32 real processors, the rest possible using the additional_cpus start option.)
These changes are all specific to the x86 architecture,
[EMAIL PROTECTED] wrote:
8472457 Total 30486950 +259% 30342823 +258%
Hmmm. The table for previous versions looked a lot more impressive.
now:8472457 Total+22014493 +259% +21870366 +258%
V2 :7172678 Total+23314404 +325% -147590 -2%
On Wed, 16 Jan 2008, Nick Piggin wrote:
Oh, just while I remember it also, something funny is that MAX_NUMNODES
can be bigger than NR_CPUS on x86. I guess one can have CPUless nodes,
but wouldn't it make sense to have an upper bound of NR_CPUS by default?
There are special configurations that
Frans Pop wrote:
[EMAIL PROTECTED] wrote:
8472457 Total 30486950 +259% 30342823 +258%
Hmmm. The table for previous versions looked a lot more impressive.
now:8472457 Total +22014493 +259% +21870366 +258%
V2 :7172678 Total+23314404 +325%
On Monday 14 January 2008 22:30, Andi Kleen wrote:
> In general there are more scaling problems like this (e.g. it also doesn't
> make sense to scale kernel threads for each CPU thread for example).
I think in a lot of ways, per-CPU kernel threads scale OK. At least
they should mostly be
On Monday 14 January 2008 22:30, Andi Kleen wrote:
In general there are more scaling problems like this (e.g. it also doesn't
make sense to scale kernel threads for each CPU thread for example).
I think in a lot of ways, per-CPU kernel threads scale OK. At least
they should mostly be dynamic,
This patchset addresses the kernel bloat that occurs when NR_CPUS is increased.
The memory numbers below are with NR_CPUS = 1024 which I've been testing (4 and
32 real processors, the rest "possible" using the additional_cpus start option.)
These changes are all specific to the x86 architecture,
Ingo Molnar wrote:
> * Andi Kleen <[EMAIL PROTECTED]> wrote:
>
>>> i.e. we've got ~22K bloat per CPU - which is not bad, but because
>>> it's a static component, it hurts smaller boxes. For distributors to
>>> enable CONFIG_NR_CPU=1024 by default i guess that bloat has to drop
>>> below 1-2K
Ingo Molnar wrote:
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
>>> 32cpus1kcpus-before 1kcpus-after
>>>7172678 Total +23314404 Total -147590 Total
>> 1kcpus-after means it's +23314404-147590, i.e. +23166814? (i.e. a 0.6%
>> reduction of
> i think this patchset already gives a net win, by moving stuff from
> NR_CPUS arrays into per_cpu area. (Travis please confirm that this is
> indeed what the numbers show)
Yes that is what his patchkit does, although I'm not sure he has addressed all
NR_CPUS
pigs yet. The basic idea came
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > i.e. we've got ~22K bloat per CPU - which is not bad, but because
> > it's a static component, it hurts smaller boxes. For distributors to
> > enable CONFIG_NR_CPU=1024 by default i guess that bloat has to drop
> > below 1-2K per CPU :-/ [that would
> i.e. we've got ~22K bloat per CPU - which is not bad, but because it's a
> static component, it hurts smaller boxes. For distributors to enable
> CONFIG_NR_CPU=1024 by default i guess that bloat has to drop below 1-2K
> per CPU :-/ [that would still mean 1-2MB total bloat but that's much
>
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > 32cpus1kcpus-before 1kcpus-after
> >7172678 Total +23314404 Total -147590 Total
>
> 1kcpus-after means it's +23314404-147590, i.e. +23166814? (i.e. a 0.6%
> reduction of the bloat?)
or if
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> This patchset addresses the kernel bloat that occurs when NR_CPUS is
> increased. The memory numbers below are with NR_CPUS = 1024 which I've
> been testing (4 and 32 real processors, the rest "possible" using the
> additional_cpus start
* [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
This patchset addresses the kernel bloat that occurs when NR_CPUS is
increased. The memory numbers below are with NR_CPUS = 1024 which I've
been testing (4 and 32 real processors, the rest possible using the
additional_cpus start option.) These
* Ingo Molnar [EMAIL PROTECTED] wrote:
32cpus1kcpus-before 1kcpus-after
7172678 Total +23314404 Total -147590 Total
1kcpus-after means it's +23314404-147590, i.e. +23166814? (i.e. a 0.6%
reduction of the bloat?)
or if it's
* Andi Kleen [EMAIL PROTECTED] wrote:
i.e. we've got ~22K bloat per CPU - which is not bad, but because
it's a static component, it hurts smaller boxes. For distributors to
enable CONFIG_NR_CPU=1024 by default i guess that bloat has to drop
below 1-2K per CPU :-/ [that would still
i.e. we've got ~22K bloat per CPU - which is not bad, but because it's a
static component, it hurts smaller boxes. For distributors to enable
CONFIG_NR_CPU=1024 by default i guess that bloat has to drop below 1-2K
per CPU :-/ [that would still mean 1-2MB total bloat but that's much
more
i think this patchset already gives a net win, by moving stuff from
NR_CPUS arrays into per_cpu area. (Travis please confirm that this is
indeed what the numbers show)
Yes that is what his patchkit does, although I'm not sure he has addressed all
NR_CPUS
pigs yet. The basic idea came out
Ingo Molnar wrote:
* Ingo Molnar [EMAIL PROTECTED] wrote:
32cpus1kcpus-before 1kcpus-after
7172678 Total +23314404 Total -147590 Total
1kcpus-after means it's +23314404-147590, i.e. +23166814? (i.e. a 0.6%
reduction of the bloat?)
Ingo Molnar wrote:
* Andi Kleen [EMAIL PROTECTED] wrote:
i.e. we've got ~22K bloat per CPU - which is not bad, but because
it's a static component, it hurts smaller boxes. For distributors to
enable CONFIG_NR_CPU=1024 by default i guess that bloat has to drop
below 1-2K per CPU :-/
This patchset addresses the kernel bloat that occurs when NR_CPUS is increased.
The memory numbers below are with NR_CPUS = 1024 which I've been testing (4 and
32 real processors, the rest possible using the additional_cpus start option.)
These changes are all specific to the x86 architecture,
This patchset addresses the kernel bloat that occurs when NR_CPUS is increased.
The memory numbers below are with NR_CPUS = 1024 which I've been testing (4 and
32 real processors, the rest "possible" using the additional_cpus start option.)
These changes are all specific to the x86 architecture,
This patchset addresses the kernel bloat that occurs when NR_CPUS is increased.
The memory numbers below are with NR_CPUS = 1024 which I've been testing (4 and
32 real processors, the rest possible using the additional_cpus start option.)
These changes are all specific to the x86 architecture,
28 matches
Mail list logo
