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). > 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 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/
