Re: [PATCH 1/4] x86_64: Switch to SPARSE_VIRTUAL

Bob Picco
2007-04-04T21:28:13Z

Christoph Lameter wrote: [Mon Apr 02 2007, 05:28:30PM EDT]
> On Mon, 2 Apr 2007, Dave Hansen wrote:
>
> > On Mon, 2007-04-02 at 13:30 -0700, Christoph Lameter wrote:
> > > On Mon, 2 Apr 2007, Dave Hansen wrote:
> > > > I completely agree, it looks like it should be faster. The code
> > > > certainly has potential benefits. But, to add this neato, apparently
> > > > more performant feature, we unfortunately have to add code. Adding the
> > > > code has a cost: code maintenance. This isn't a runtime cost, but it is
> > > > a real, honest to goodness tradeoff.
> > >
> > > Its just the opposite. The vmemmap code is so efficient that we can remove
> > > lots of other code and gops of these alternate implementations.
> >
> > We do want to make sure that there isn't anyone relying on these. Are
> > you thinking of simple sparsemem vs. extreme vs. sparsemem vmemmap? Or,
> > are you thinking of sparsemem vs. discontig?
>
> I am thinking sparsemem default and then get rid discontig, flatmem etc.
> On many platforms this will work. Flatmem for embedded could just be a
> variation on sparse_virtual.
>
> > Amen, brother. I'd love to see DISCONTIG die, with sufficient testing,
> > of course. Andi, do you have any ideas on how to get sparsemem out of
> > the 'experimental' phase?
>
> Note that these arguments on DISCONTIG are flame bait for many SGIers.
> We usually see this as an attack on DISCONTIG/VMEMMAP which is the
> existing best performing implementation for page_to_pfn and vice
> versa. Please lets stop the polarization. We want one consistent scheme
> to manage memory everywhere. I do not care what its called as long as it
> covers all the bases and is not a glaring performance regresssion (like
> SPARSEMEM so far).
Well you must have forgotten about these two postings in regards to
performance numbers:
http://marc.info/?l=linux-ia64&m=111990276501051&w=2
and
http://marc.info/?l=linux-kernel&m=116664638611634&w=2
.

I took your first patchset and ran some numbers on an amd64 machine with
two dual core sockets and 4Gb of memory. More iterations should be done
and perhaps larger number of tasks. The aim7 numbers are below.

bob

2.6.21-rc5+sparsemem
Benchmark Version Machine Run Date
AIM Multiuser Benchmark - Suite VII "1.1" rcc5 Apr 2 05:04:33 2007

Tasks Jobs/Min JTI Real CPU Jobs/sec/task
1 13.8 100 421.3 2.2 0.2303
101 527.8 97 1113.8 111.5 0.0871
201 565.0 97 2070.6 222.7 0.0468
301 570.9 96 3068.7 334.7 0.0316
401 573.0 97 4072.7 445.6 0.0238
501 583.3 99 4998.5 558.6 0.0194
601 583.8 99 5991.1 672.9 0.0162

2.6.21-rc5+sparsemem+patchset
Benchmark Version Machine Run Date
AIM Multiuser Benchmark - Suite VII "1.1" vmem Apr 4 02:22:24 2007

Tasks Jobs/Min JTI Real CPU Jobs/sec/task
1 13.7 100 424.0 2.1 0.2288
101 500.3 97 1175.0 112.0 0.0826
201 554.2 97 2111.0 223.6 0.0460
301 578.5 97 3028.3 334.9 0.0320
401 586.2 97 3981.3 448.1 0.0244
501 584.2 99 4990.8 561.8 0.0194
601 584.4 98 5985.2 675.5 0.0162

>
> > I have noticed before that sparsemem should be able to cover the flatmem
> > case if we make MAX_PHYSMEM_BITS == SECTION_SIZE_BITS and massage from
> > there.
>
> Right. But for embedded the memorymap base cannot be constant because
> they may not be able to have a fixed address in memory. So memory map
> needs to become a variable.
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: email@kvack.org