identity mapping ram to save time/effort
Posted: Fri Mar 17, 2006 7:50 pm
ok, so I've been purusing windows 2000 internals books, and noticed an interesting little bit of the memory map.
the area from 0x80000000 to 0xa0000000 is an identity map of the first 512 megs of ram.
After thinking about why they would do that, I came to a realization and am actually very surprised that noone here has mentioned it before.
By doing this, we can successfully avoid a lot of temporary mappings and/or page dir switches when mapping/unmapping page tables.
Here's the concept, you have two seperate page pools, one for "low" memory and one for "high" memory. high memory is simply whatever is outside of your 1:1 memory window. You only allocate page dirs/page tables from low memory pool. What this gains us is firstly, you can read/write the page directory of a "new process" without any temporary mappings at all, no invalidating tlb, nothing, you just pick a page dir, add a constant to it to get it's virtual address. pretty much the same with page tables.
Using this technique, we sacrafice a certain large portion of the virtual address space for convinience and possibly speed (windows 2000 uses 4MB pages for this region to avoid invalidating the TLB for everything else whenever it access this region).
I've implemented this in my OS (i chose 256 megs for "low" memory size), and I've changed my Process::mapPage() code to use this technique, the code is a quater of the size.
What do you guys think about this? Is it something you were aware of and dismissed due to faults, or is it just not an idea floating around in the amature OS dev community?
proxy
the area from 0x80000000 to 0xa0000000 is an identity map of the first 512 megs of ram.
After thinking about why they would do that, I came to a realization and am actually very surprised that noone here has mentioned it before.
By doing this, we can successfully avoid a lot of temporary mappings and/or page dir switches when mapping/unmapping page tables.
Here's the concept, you have two seperate page pools, one for "low" memory and one for "high" memory. high memory is simply whatever is outside of your 1:1 memory window. You only allocate page dirs/page tables from low memory pool. What this gains us is firstly, you can read/write the page directory of a "new process" without any temporary mappings at all, no invalidating tlb, nothing, you just pick a page dir, add a constant to it to get it's virtual address. pretty much the same with page tables.
Using this technique, we sacrafice a certain large portion of the virtual address space for convinience and possibly speed (windows 2000 uses 4MB pages for this region to avoid invalidating the TLB for everything else whenever it access this region).
I've implemented this in my OS (i chose 256 megs for "low" memory size), and I've changed my Process::mapPage() code to use this technique, the code is a quater of the size.
What do you guys think about this? Is it something you were aware of and dismissed due to faults, or is it just not an idea floating around in the amature OS dev community?
proxy
well guess that answers that question 