Messages in this thread | | | From | Dan Malek <> | Subject | Re: increased translation cache footprint in v2.6 | Date | Mon, 27 Jun 2005 16:35:41 -0400 |
| |
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/
| |