Why the accessed and dirty bits act as redundant permission bits

[comex]

ARM implements something similar with its accessed bit ("Access flag"). To quote the ARM manual:

ARMv8.0 requires that software manages the Access flag. This means an Access flag fault is generated whenever an attempt is made to read into the TLB a translation table descriptor entry for which the value of Access flag is 0.

The Access flag mechanism expects that, when an Access flag fault occurs, software resets the Access flag to 1 in the translation table entry that caused the fault. This prevents the fault occurring the next time that memory location is accessed. Entries with the Access flag set to 0 are never held in the TLB, meaning software does not have to flush the entry from the TLB after setting the flag.

ARMv8.1 adds optional hardware management of the Access flag.

So, on ARM processors that don't support hardware management, if you want to track accessed-ness, I can think of three reasons to use the Access flag instead of just changing the permission or validity bits:

1. Code sharing between hardware that does and doesn't support hardware Access flag management. You can read the same bit to determine whether a page has been accessed; it's just a question of whether hardware or software sets that bit.
2. If you have a simple memory management design that uses the page table as the sole data structure to track pages – as opposed to having a separate data structure which is just mirrored to the page table – then you wouldn't know whether a given page is "actually" invalid, or whether it's just temporarily set as invalid because you want to track whether it's been accessed. Having a separate bit in each page table entry lets you tell the difference.
3. The special provision that you don't have to flush the TLB (which has a performance cost) when setting the Access flag.

I don't know whether 3 also applies to RISC-V, but 1 and 2 would apply.

Edit: And on both architectures, the reason hardware support isn't required is to allow for simpler hardware designs.

[sgmarz]

Thanks for your input. You did a fantastic job summarizing the differences in design choices.

[fintelia]

#3 doesn't apply to RISC-V: the implementation is allowed to cache both valid and invalid page table entries. Though in general design sense you don't need to do TLB flushes when increasing the permissions of a page:

For the special cases of increasing the permissions on a leaf PTE and changing an invalid PTE to a valid leaf, software may choose to execute the SFENCE.VMA lazily. After modifying the PTE but before executing SFENCE.VMA, either the new or old permissions will be used. In the latter case, a page-fault exception might occur, at which point software should execute SFENCE.VMA...

[sgmarz]

I'm going to close this as this is not really an issue, but it helps illuminate the architecture's decisions.