Re: increased translation cache footprint in v2.6

[Dan Malek <dan@embeddededge.com>]

On Jun 27, 2005, at 3:50 PM, David S. Miller wrote:

> I think you're making this problem more complex than it really
> is.  There is no reason at all to hold page tables for the direct
> physical memory mappings of lowmem if you have any control whatsoever
> over the TLB miss handler.

I'm not one to make it more complex, I just want to cover
all of the possibilities :-)  The "compute kernel" part of
it needs to be generic for all of the possibilities.   Like I mentioned.
we have a quite configurable address space for mapping text,
data, IO, and uncached spaces.  In addition, we have execute
in place out of flash and other embedded custom options.
I was hoping to find a solution where the kernel TLBs could
be dynamically loaded as well, with the standard look up
algorithm.  Yes, I still need a kernel path for the special
case processing of other than 4K pages, but it would be nice
to keep that generic as well.

I agree, it's rather trivial to fabricate the kernel text/data
large page sizes on the fly, but there are other address spaces
that would also benefit from such mapping.  I'd like to find a
complete solution to this, and I am working on it as time permits.
I'd rather not try to define a half-baked solution in the future, as
I sometimes have to do of code written years ago :-)

Even if we don't use the page tables, we still need to create
them, as the Abatron BDI2000 has knowledge of Linux page
tables.  When using this jtag debugger, it performs virtual->physical
translations of addresses not currently mapped by the MMU.

Thanks.


	-- Dan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/