Re: sparsemem support for mips with highmem

[David VomLehn <dvomlehn@cisco.com>]

Christoph Lameter wrote:
> David VomLehn wrote:
>
> > On MIPS processors, the kernel runs in unmapped memory, i.e. the TLB
> > isn't even
> > used, so I don't think you can use that trick. So, this comment doesn't
> > apply to
> > all processors.
> In that case you have a choice between the overhead of sparsemem lookups in
> every pfn_to_page or using TLB entries to create a virtually mapped memmap
> which may create TLB pressure.
>
> 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 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.
If we took this approach, we could then have a single, simple memmap array where 
pfn_to_page looks just about the same as it looks with a flat memory model.
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.
Anyone with more in-depth MIPS processor architecture knowledge care to weigh in 
on this?
--
David VomLehn