4 ms·

> if there is some easier way to get the D flag cleared you can use that. Is there though? I didn't know about the dirty bit, so obviously I don't know much ab

> if there is some easier way to get the D flag cleared you can use that. Is there though? I didn't know about the dirty bit, so obviously I don't know much about x86 TLB, but I'm having trouble imagining any reasonable implementation where clearing the dirty bit wouldn't itself require a shootdown. Have you seen somewhere claim that MADV_FREE allows avoiding a shootdown? The man page doesn't say that and I am pretty sure I heard before that it does not, but would be very interested to know if that's incorrect.

eqvinox 6y ago
> Have you seen somewhere claim that MADV_FREE allows avoiding a shootdown? I haven't, and after looking at mm/madvise.c [ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/madvise.c#n700 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... ] I guess it doesn't. Also, the unmapping happens immediately. MADV_DONTNEED doesn't help either, it also seems to invalidate immediately. That only leaves MADV_REMOVE, which AFAIK doesn't work on anonymous mappings... sigh [Edit: good thing I don't write allocators :D]
eqvinox 6y ago
Intel docs say this on CPU behaviour: https://software.intel.com/content/www/us/en/develop/download/intel-64-and-ia-32-architectures-sdm-combined-volumes-1-2a-2b-2c-2d-3a-3b-3c-3d-and-4.html https://software.intel.com/content/www/us/en/develop/downloa... [4.8 ACCESSED AND DIRTY FLAGS] Memory-management software may clear these flags when a page or a paging structure is initially loaded into physical memory. These flags are “sticky,” meaning that, once set, the processor does not clear them; only software can clear them. A processor may cache information from the paging-structure entries in TLBs and paging-structure caches (see Section 4.10). This fact implies that, if software changes an accessed flag or a dirty flag from 1 to 0, the processor might not set the corresponding bit in memory on a subsequent access using an affected linear address (see Section 4.10.4.3). See Section 4.10.4.2 for how software can ensure that these bits are updated as desired. [4.10.4 Invalidation of TLBs and Paging-Structure Caches] [4.10.4.2 Recommended Invalidation] ... so, I guess, yeah, this doesn't really help :|

eqvinox 6y ago

> Have you seen somewhere claim that MADV_FREE allows avoiding a shootdown? I haven't, and after looking at mm/madvise.c [ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/madvise.c#n700 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... ] I guess it doesn't. Also, the unmapping happens immediately. MADV_DONTNEED doesn't help either, it also seems to invalidate immediately. That only leaves MADV_REMOVE, which AFAIK doesn't work on anonymous mappings... sigh [Edit: good thing I don't write allocators :D]

eqvinox 6y ago

Intel docs say this on CPU behaviour: https://software.intel.com/content/www/us/en/develop/download/intel-64-and-ia-32-architectures-sdm-combined-volumes-1-2a-2b-2c-2d-3a-3b-3c-3d-and-4.html https://software.intel.com/content/www/us/en/develop/downloa... [4.8 ACCESSED AND DIRTY FLAGS] Memory-management software may clear these flags when a page or a paging structure is initially loaded into physical memory. These flags are “sticky,” meaning that, once set, the processor does not clear them; only software can clear them. A processor may cache information from the paging-structure entries in TLBs and paging-structure caches (see Section 4.10). This fact implies that, if software changes an accessed flag or a dirty flag from 1 to 0, the processor might not set the corresponding bit in memory on a subsequent access using an affected linear address (see Section 4.10.4.3). See Section 4.10.4.2 for how software can ensure that these bits are updated as desired. [4.10.4 Invalidation of TLBs and Paging-Structure Caches] [4.10.4.2 Recommended Invalidation] ... so, I guess, yeah, this doesn't really help :|