The following are additional details regarding invalidations. In some embodiments, the TidalPod includes first level page tables, which perform hardware translation from the user space (e.g., guest program run in user space) to what the guest operating system believes is its physical space (i.e., the first level page table mapping translates virtual addresses into what the guest OS believes to be physical addresses). As described above, what the guest OS believes to be physical addresses are guest physical addresses managed by the hyper-kernel (e.g., hyper-kernel host addresses), which then go through another level of page address translation, in hardware (e.g., via a second level page table), where the guest physical addresses are converted or translated into true physical addresses of the pages. In some embodiments, a page is invalidated by erasing it from the second level page table. Garbage collection can then be run, or memory can be returned to a free pool, etc., as the nodes can no longer access the invalidated page of memory.
After this, all write operations to a page marked Exclusive will not generate any stalls, since they can be locally read and written into on the node, and no other copies exist (e.g., pages invalidated by erasing them from the second level page table, as described above).
In some embodiments, the NAM abides by the same protocol described above. As with any other node in the TidalPod, the NAM also has valid and invalid pages. For example:
1. All pages in the NAM start off as invalid. In some embodiments, if a page becomes valid, it is marked as secondary, because the page on the NAM cannot be written into (only read from).