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 t
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
> > migh
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 overhead
>
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 sta
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.
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 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 indicate
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 on s
> 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 [EM
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
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 sparsem
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 s
14 matches
Mail list logo
