[Top] [All Lists]

Re: sparsemem support for mips with highmem

To: David VomLehn <>
Subject: Re: sparsemem support for mips with highmem
From: Christoph Lameter <>
Date: Wed, 20 Aug 2008 08:58:51 -0500
Cc: Randy Dunlap <>, C Michael Sundius <>, Dave Hansen <>, Thomas Bogendoerfer <>,,,, Andy Whitcroft <>
In-reply-to: <>
Original-recipient: rfc822;
References: <> <1218753308.23641.56.camel@nimitz> <> <> <1218815299.23641.80.camel@nimitz> <> <> <> <1218821875.23641.103.camel@nimitz> <> <> <> <> <> <>
User-agent: Thunderbird (Windows/20080708)
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.

<Prev in Thread] Current Thread [Next in Thread>