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 [EMAIL PROTECTED] For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: <a href=mailto:"[EMAIL PROTECTED]"> [EMAIL PROTECTED] </a> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
