MMU Page Translation
Where are the MMU Page Translation Tables stored?
either in Main Memory(RAM) or part of the MMU Hardware? |
Q: Is this a test question/homework assignment ;)?
Q: What do you think the MMU would do with them if it could somehow "store them in hardware"? Look here for more details: http://tldp.org/LDP/tlk/mm/memory.html http://en.wikipedia.org/wiki/Memory_management_unit |
This is not a test qn/assignment. I wanted to know the internals of memory management.
For each Translation , CPU needs to lookup the translation table in memory which is a slow device compared to CPU. So , if it could be stored in hardware then the translation will be speeded up. Correct me if i am wrong. |
OK, fair enough :)
Quote:
http://www.kernel.org/doc/gorman/htm...rstand006.html So yes, everything the kernel does ultimately uses memory. The page tables themselves are created and maintained in kernel memory. And yes, the kernel is optimized to make use of hardware resources (such as the TLB) to as great an extent as possible. |
I know this would look a bit old post, But I do really have a related question here:
Is there anyway in Linux or any other similar OSes to control the TLB or play around with it, I really want to although I do know this is something nowadays totally is done by the MMU unit which is a hardware setting, but we have a new comers of multi/many core OSes and I have no idea how they handle that in the future, so you guys have any idea how to play with the TLBs in linux ? |
Interaction with TLB is handled by the kernel and it's limited to flushing invalid TLB entries, which may be necessary when some mapping is changed or context switch happens. Flushing is of course not a desired operation as the mapping has to be re-read from memory which slows things down. There's not much else one can do with TLB as it operates mostly by itself.
|
Everything that is "low-level guts related to" memory management will always be found in the /arch/whatever directory, since such things are by-definition "architecture specific." Things like, "what the actual bits mean, how the data-structures are to be arranged for this-or-that CPU, how the control-registers have to be stuffed," and so on, will be found (only...) here. Everything above this will be more-or-less an abstraction.
|
All times are GMT -5. The time now is 08:43 PM. |