Re: sparsemem support for mips with highmem

[Christoph Lameter <cl@linux-foundation.org>]

David VomLehn wrote:

>> The virtually mapped memmap results in smaller code and is typically more
>> effective since the processor caches the TLB entries.
> 
> I'm pretty ignorant on this subject, but I think this is worth
> discussing. On a MIPS processor, access to low memory bypasses the TLB
> entirely. I think what you are suggesting is to use mapped addresses to
> make all of low memory virtually contiguous. On a MIPS processor, we

No the virtual area is only used to map the memory map (the array of page
structs). That is just a small fraction of memory.


> could do this by allocating a "wired" TLB entry for each physically
> contiguous block of memory. Wired TLB entries are never replaced, so
> they are very efficient for long-lived mappings such as this. Using the
> TLB in this way does increase TLB pressure, but most platforms probably
> have a very small number of "holes" in their memory. So, this may be a
> small overhead.

That would consume precious resources.

Just place the memmap into the vmalloc area gets you there. TLB entries should
be loaded on demand.


> If I'm understand what you are suggesting correctly (a big if), the
> downside is that we'd pay the cost of a TLB match for each non-cached
> low memory data access. It seems to me that would be a higher cost than
> having the occasional, more expensive, sparsemem lookup in pfn_to_page.

The cost going through a TLB mapping is only incurred for accesses to the
memmap array. Not for general memory accesses.

--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>