OSDev.org

I know if I change the page table, I need to invalidate TLB to make the changes visible to CPU. But I don't know if TLB has a write-back mechanism. If the CPU writes to a linear address, does it set the dirty bit in TLB entry and wait for a writeback or it changes PTE directly?

Intel Manual says:

Whenever there is a write to a linear address, the processor sets the dirty flag (if it is not already set) in the pagingstructure
entry that identifies the final physical address for the linear address (either a PTE or a paging-structure
entry in which the PS flag is 1).

Does this means the dirty bit is set on PTE directly?

haolee wrote:I know if I change the page table, I need to invalidate TLB to make the changes visible to CPU. But I don't know if TLB has a write-back mechanism. If the CPU writes to a linear address, does it set the dirty bit in TLB entry and wait for a writeback or it changes PTE directly?

Intel Manual says:

Whenever there is a write to a linear address, the processor sets the dirty flag (if it is not already set) in the pagingstructure
entry that identifies the final physical address for the linear address (either a PTE or a paging-structure
entry in which the PS flag is 1).

Does this means the dirty bit is set on PTE directly?

It is set in the PTE directly, but I assume it'll also be set in the TLB entry as well so it knows that it doesn't need to write it again in the future.

I don't know the order of the writes to the memory that triggered the dirty bit being set and the PTE write setting the dirty bit, or whether those two writes are atomic. I'd assume they're either atomically written together or the PTE updated first, as writing the page data without marking the PTE as dirty can result in a consistency race (another processor might reuse that page thinking it is clean, when it is not.)

In short, other than invalidating stale TLB entries for updated PTE entries, TLB management should be transparent on x86, including the management of the accessed and dirty bits of the PTE.

In contrast, architectures that use software managed TLBs do leave marking of PTE as dirty to the software. The MMU will fault on write, for example, UNLESS the TLB is marked dirty. In this case, the dirty bit is effectively a write permission bit. In reality, the x86 TLB is probably doing the same thing, but in hardware:

- CPU store unit writes to memory
- TLB entry is looked up
- TLB entry doesn't have dirty bit set
- MMU sets the dirty bit in the PTE, and updates the TLB with the new dirty status
- MMU returns the now dirty enabled TLB to the store unit to write the data

thewrongchristian wrote:
It is set in the PTE directly, but I assume it'll also be set in the TLB entry as well so it knows that it doesn't need to write it again in the future.

I don't know the order of the writes to the memory that triggered the dirty bit being set and the PTE write setting the dirty bit, or whether those two writes are atomic. I'd assume they're either atomically written together or the PTE updated first, as writing the page data without marking the PTE as dirty can result in a consistency race (another processor might reuse that page thinking it is clean, when it is not.)

In short, other than invalidating stale TLB entries for updated PTE entries, TLB management should be transparent on x86, including the management of the accessed and dirty bits of the PTE.

In contrast, architectures that use software managed TLBs do leave marking of PTE as dirty to the software. The MMU will fault on write, for example, UNLESS the TLB is marked dirty. In this case, the dirty bit is effectively a write permission bit. In reality, the x86 TLB is probably doing the same thing, but in hardware:

- CPU store unit writes to memory
- TLB entry is looked up
- TLB entry doesn't have dirty bit set
- MMU sets the dirty bit in the PTE, and updates the TLB with the new dirty status
- MMU returns the now dirty enabled TLB to the store unit to write the data

Thanks! This is really helpful.