OSDev.org

Hello.

I've got a page directory mapped to somewhere in memory. Then I edit this virtual location to change some other page´s mapping.
When I invlpg the mapping I've just changed and the virtual memory where pdir is mapped is not write-through, is it possible that my invlpg won't be effective because processor would use old version of page directory?

You use INVLPG on an address in memory. All translation entries corresponding to that address are discarded.

The next time the address is used, the page table will be walked, which initially loads from the cache (which is kept coherent between processors), or from system memory if it can't be found. The only way to break this is to have a change in one cache in one core, and one other core set to ignore the cache for such an address. Which means the updating code must be write-back and the using code must be uncacheable for the same physical address, which is unlikely

In general, the architecture does not support cases where one core uses the same block of physical memory with a different caching scheme than another core, so if that happens your code is wrong anyway.

Hi,

lexected wrote:I've got a page directory mapped to somewhere in memory. Then I edit this virtual location to change some other page´s mapping.
When I invlpg the mapping I've just changed and the virtual memory where pdir is mapped is not write-through, is it possible that my invlpg won't be effective because processor would use old version of page directory?

When the CPU has to fetch data for a page directory or page table, it can/will fetch that data from the CPU's "data cache", and because the CPU's data caches are "cache coherent" it doesn't matter (for correctness) if the actual physical memory being used for the page directory or page table is "write-back" or "write-through" or "uncached" or whatever. The CPU's TLBs are not cache coherent and therefore you will have to invalidate TLBs (regardless of how the physical memory is/isn't cached). Note: For multi-CPU systems it is possible to break cache coherency for the data caches by (e.g.) mis-configuring the MTRRs (so that an area of the physical address space has different "cache-ability" for different CPUs);and I've assumed MTRRs haven't been mis-configured in this way.

Imagine you've got 4 KiB of data in physical memory that is used for:

• a normal page at virtual address 0x12345000
• a page directory containing entries, where each entry effects page tables that each control a 4 MiB area of the virtual address space
• a page table containing entries where each entry effects 4 KiB of the virtual address space

Now; if you write to this physical memory (e.g. using the "normal page at virtual address 0x12345000"); then you don't need to invalidate the page at virtual address 0x12345000 (as any TLB entry pointing to it remains the same); will have to invalidate TLBs for everything in any effected 4 MiB area of the virtual address space (due to changing data that effects page directory entries); and will have to invalidate TLBs for everything in any effected 4 KiB area of the virtual address space (due to changing data that effects page table entries).

Notes:

• The scenario I've described above is typical for "plain 32-bit paging" if/when the recursive mapping trick is used
• If you do have to invalidate a large area (e.g. 4 MiB of the virtual address space), then it's possibly faster to invalidate all TLB entries (e.g. by reloading CR3, if none of the TLB entries/pages are "global") than it is to do invlpg 1024 times in a loop.
• Where I've said "will have to invalidate" above, to be technically correct I really should've said "may have to invalidate" because there are lazy TLB invalidation schemes that avoid the need to do explicit TLB invalidation in some cases.

Cheers,

Brendan

Thank you both, I'll look for my problem elsewhere.
One more thing: does the dirty bit on a page have something to do with the cache or it's a distant constellation?

The dirty bit simply means the page was written to. You can use that to see if pages have been modified since you last looked at them (saved them to disk, perhaps).