Martin Bligh wrote: > Christoph Lameter wrote: >> On Fri, 16 Mar 2007, Martin Bligh wrote: >> >>> You have to do some sort of lookup anyway, and Andy seemed to have them >>> all folded into one. >> >> What lookup would you need to do? On x86_64 even the TLB use is hidden >> by the existing 2M entries for 1-1 mappings. >> >>> Or are you trying to avoid this by going to back to the crud we had >>> in 2.4 where we pretend mem_map is one big array, indexed by pfn with >>> huge sparsely mapped holes in it? >> >> Yes that the advanced way of doing it rather than adding useless >> custom lookups. > > For starters, you can't do that sparse a mapping on a 32 bit system. > I'll let Andy explain the rest of it. > >>> Would be nice to work out (and document somewhere) what the pros and >>> cons of virtual memmap vs sparsemem were - ISTR one of the arguments >>> was extremely sparsely layed out machines, and you needed sparsemem >>> for that. But right now we have 3 solutions, which is not a good >>> situation. >> >> Please read my posts to linux-mm on that subject. We discussed it last >> year in detail and the agreement was that the sparsemem crud needs to >> be taken out. Kame-san posted patches to do that. > > "the agreement"? So Andy agreed to taking it out? Or you and Kame did?
The discussions centred around some patches from Kame which introduced a SPARSMEM sub-model with a virtual memory map. That was a supprisingly clean change which if followed through to its logical conclusion would remove a significant chunk of architecture specific vmemmap implementation from ia64, and (as I understand it) was likely to allow the same to be reused in s390x as well. SPARSEMEM would still have its useful modes for smaller memory systems. -apw - 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/
