MADV_REMOVE是否会触发TLB shootdown？其潜在不良影响有哪些

首先明确核心结论：MADV_REMOVE在你描述的file-backed共享tmpfs映射场景下，必然会触发TLB shootdown。
原因很简单：MADV_REMOVE的内核逻辑是直接释放指定地址范围对应的底层文件页，同时会移除所有进程中映射了这些被释放页的PTE（页表项）。只要存在多CPU核心上的进程持有这些页的TLB缓存，内核就必须发起TLB shootdown来保证所有CPU的TLB一致性，这和MADV_DONTNEED在共享映射下的行为逻辑是一致的。

MADV_REMOVE的潜在负面效应 #

• 不可逆的数据丢失风险：和MADV_DONTNEED对file-backed映射会先刷脏再释放、仅清除非必要页缓存的逻辑不同，MADV_REMOVE会直接丢弃对应的tmpfs页，无论是否为脏页，也不会触发任何同步校验。如果你清理的范围包含还未被同步、或者正在被其他进程读写的页，其他进程访问对应地址时会直接拿到全零页，相当于数据被直接清空，对并发访问的业务逻辑会造成毁灭性影响。
• 严重的锁竞争开销：MADV_REMOVE执行过程中会持有对应tmpfs inode的i_mmap_rwsem写锁，以及目标地址空间的页表锁。如果这段内存映射被大量进程并发访问，这个锁会阻塞所有其他进程对该映射范围的页错误处理、页表修改操作，可能造成短时间内大量进程阻塞，对延迟敏感的业务影响非常明显。
• 额外的页错误开销：和MADV_FREE只是标记页面可回收、在内存压力真正出现前还可以被访问恢复的逻辑不同，MADV_REMOVE一旦执行完成，页面就已经被直接释放，没有任何恢复的可能，哪怕后续立刻有进程要访问对应地址，也只能重新分配零页，会带来额外的缺页开销。

你的场景下的使用建议 #

如果只是清理未使用的页面，优先选择MADV_DONTNEED而非MADV_REMOVE：前者对tmpfs的file-backed映射会先确认脏页状态，不会主动丢弃未同步的业务数据，安全程度高很多。如果可以容忍一定的TLB shootdown开销，也可以分批小范围执行内存建议操作，不要一次性处理GB级别的连续内存范围，降低单次操作的锁持有时间和TLB shootdown的影响范围。

内容的提问来源于stack exchange，提问作者Locke