Updated version against mainline. Looks even a bit cleaner.
x86_64: Make sparsemem/vmemmap the default memory model V2
V1->V2:
- Rediff against new upstream x86 code that unifies the Kconfig files.
Use sparsemem as the only memory model for UP, SMP and NUMA.
Measurements indic
On Thu, 15 Nov 2007 18:24:54 -0800 (PST) Christoph Lameter <[EMAIL PROTECTED]>
wrote:
> On Thu, 15 Nov 2007, Andrew Morton wrote:
>
> > Unfortunately some loon has gone and merged the i386 and x86_64 Kconfig
> > files. I was fixing that up but I worry what effects these Kconfig changes
> >
On Thu, 15 Nov 2007, Andrew Morton wrote:
> Unfortunately some loon has gone and merged the i386 and x86_64 Kconfig
> files. I was fixing that up but I worry what effects these Kconfig changes
> might have on, for example, i386 NUMA setups.
>
> So I'll duck this version, sorry.
Is there a tree
On Mon, 12 Nov 2007 19:42:31 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> x86_64: Make sparsemem/vmemmap the default memory model
>
> Use sparsemem as the only memory model for UP, SMP and NUMA.
> Measurements indicate that DISCONTIGMEM has a higher overhea
On Mon, 12 Nov 2007 19:42:31 -0800 (PST)
Christoph Lameter [EMAIL PROTECTED] wrote:
x86_64: Make sparsemem/vmemmap the default memory model
Use sparsemem as the only memory model for UP, SMP and NUMA.
Measurements indicate that DISCONTIGMEM has a higher overhead
than sparsemem. And FLATMEMs
On Thu, 15 Nov 2007 18:24:54 -0800 (PST) Christoph Lameter [EMAIL PROTECTED]
wrote:
On Thu, 15 Nov 2007, Andrew Morton wrote:
Unfortunately some loon has gone and merged the i386 and x86_64 Kconfig
files. I was fixing that up but I worry what effects these Kconfig changes
might have
On Thu, 15 Nov 2007, Andrew Morton wrote:
Unfortunately some loon has gone and merged the i386 and x86_64 Kconfig
files. I was fixing that up but I worry what effects these Kconfig changes
might have on, for example, i386 NUMA setups.
So I'll duck this version, sorry.
Is there a tree that
Updated version against mainline. Looks even a bit cleaner.
x86_64: Make sparsemem/vmemmap the default memory model V2
V1-V2:
- Rediff against new upstream x86 code that unifies the Kconfig files.
Use sparsemem as the only memory model for UP, SMP and NUMA.
Measurements indicate
On Tue, 13 November 2007 13:52:17 -0800, Christoph Lameter wrote:
>
> Could you run your own test to verify?
You bastard! You know I'm too lazy to do that. ;)
As long as the order-0 number is stable across multiple runs I don't
mind. The numbers just looked suspiciously as if they were not
On Tue, 13 Nov 2007, Jörn Engel wrote:
> On Mon, 12 November 2007 20:41:10 -0800, Christoph Lameter wrote:
> > On Mon, 12 Nov 2007, Ray Lee wrote:
> >
> > > Discontig obviously needs to die. However, FlatMem is consistently
> > > faster, averaging about 2.1% better overall for your numbers
On Mon, 12 November 2007 20:41:10 -0800, Christoph Lameter wrote:
> On Mon, 12 Nov 2007, Ray Lee wrote:
>
> > Discontig obviously needs to die. However, FlatMem is consistently
> > faster, averaging about 2.1% better overall for your numbers above. Is
> > the page allocator not, erm, a fast path,
On Mon, 12 November 2007 20:41:10 -0800, Christoph Lameter wrote:
On Mon, 12 Nov 2007, Ray Lee wrote:
Discontig obviously needs to die. However, FlatMem is consistently
faster, averaging about 2.1% better overall for your numbers above. Is
the page allocator not, erm, a fast path, where
On Tue, 13 Nov 2007, Jörn Engel wrote:
On Mon, 12 November 2007 20:41:10 -0800, Christoph Lameter wrote:
On Mon, 12 Nov 2007, Ray Lee wrote:
Discontig obviously needs to die. However, FlatMem is consistently
faster, averaging about 2.1% better overall for your numbers above. Is
the
On Tue, 13 November 2007 13:52:17 -0800, Christoph Lameter wrote:
Could you run your own test to verify?
You bastard! You know I'm too lazy to do that. ;)
As long as the order-0 number is stable across multiple runs I don't
mind. The numbers just looked suspiciously as if they were not
On Mon, 12 Nov 2007, Ray Lee wrote:
> Discontig obviously needs to die. However, FlatMem is consistently
> faster, averaging about 2.1% better overall for your numbers above. Is
> the page allocator not, erm, a fast path, where that matters?
>
> Order FlatSparse % diff
> 0 639 641
On Nov 12, 2007 7:42 PM, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> Ok here is the patch to remove DISCONTIG and FLATMEM
>
> x86_64: Make sparsemem/vmemmap the default memory model
>
> Use sparsemem as the only memory model for UP, SMP and NUMA.
> Measurements indica
DISCONTIG and FLATMEM
x86_64: Make sparsemem/vmemmap the default memory model
Use sparsemem as the only memory model for UP, SMP and NUMA.
Measurements indicate that DISCONTIGMEM has a higher overhead
than sparsemem. And FLATMEMs benefits are minimal. So I think its
best to simply standardize o
> Hmmm... More memory free? How did that happen? More pages cached for some
> reason. The total available memory is increased by 8k.
Nice. Looks all reasonable. Thanks for the numbers.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Tue, 13 Nov 2007, Andi Kleen wrote:
> On Tuesday 13 November 2007 00:52:14 Christoph Lameter wrote:
> > Use sparsemem as the only memory model for UP, SMP and NUMA.
> >
> > Measurements indicate that DISCONTIGMEM has a higher
> > overhead than sparsemem. And FLATMEMs benefits are minimal. So
On Tuesday 13 November 2007 00:52:14 Christoph Lameter wrote:
> Use sparsemem as the only memory model for UP, SMP and NUMA.
>
> Measurements indicate that DISCONTIGMEM has a higher
> overhead than sparsemem. And FLATMEMs benefits are minimal. So I think its
> best to simply standardize on
Use sparsemem as the only memory model for UP, SMP and NUMA.
Measurements indicate that DISCONTIGMEM has a higher
overhead than sparsemem. And FLATMEMs benefits are minimal. So I think its
best to simply standardize on sparsemem.
Results of page allocator tests (test can be had via git from the
Use sparsemem as the only memory model for UP, SMP and NUMA.
Measurements indicate that DISCONTIGMEM has a higher
overhead than sparsemem. And FLATMEMs benefits are minimal. So I think its
best to simply standardize on sparsemem.
Results of page allocator tests (test can be had via git from the
On Tuesday 13 November 2007 00:52:14 Christoph Lameter wrote:
Use sparsemem as the only memory model for UP, SMP and NUMA.
Measurements indicate that DISCONTIGMEM has a higher
overhead than sparsemem. And FLATMEMs benefits are minimal. So I think its
best to simply standardize on sparsemem.
On Tue, 13 Nov 2007, Andi Kleen wrote:
On Tuesday 13 November 2007 00:52:14 Christoph Lameter wrote:
Use sparsemem as the only memory model for UP, SMP and NUMA.
Measurements indicate that DISCONTIGMEM has a higher
overhead than sparsemem. And FLATMEMs benefits are minimal. So I think
Hmmm... More memory free? How did that happen? More pages cached for some
reason. The total available memory is increased by 8k.
Nice. Looks all reasonable. Thanks for the numbers.
-Andi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
: Make sparsemem/vmemmap the default memory model
Use sparsemem as the only memory model for UP, SMP and NUMA.
Measurements indicate that DISCONTIGMEM has a higher overhead
than sparsemem. And FLATMEMs benefits are minimal. So I think its
best to simply standardize on sparsemem.
Results of page
On Nov 12, 2007 7:42 PM, Christoph Lameter [EMAIL PROTECTED] wrote:
Ok here is the patch to remove DISCONTIG and FLATMEM
x86_64: Make sparsemem/vmemmap the default memory model
Use sparsemem as the only memory model for UP, SMP and NUMA.
Measurements indicate that DISCONTIGMEM has a higher
On Mon, 12 Nov 2007, Ray Lee wrote:
Discontig obviously needs to die. However, FlatMem is consistently
faster, averaging about 2.1% better overall for your numbers above. Is
the page allocator not, erm, a fast path, where that matters?
Order FlatSparse % diff
0 639 641 0.3
28 matches
Mail list logo
