Re: Is anonymous memory part of the page cache on Linux?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12.03.21 23:45, Matthew Wilcox wrote:
On Fri, Mar 12, 2021 at 04:41:55PM +0100, Peter Weber wrote:
Thank you Matthew!


Am 2021-03-12 16:15, schrieb Matthew Wilcox:
The wikipedia diagram is wrong.  Anonymous memory is not handled by the
page cache.

Is it roughly right to say, that the virtual memory uses page tables to
handle anonymous memory?


You'll have to distinguish between private and shared anonymous memory.


"private anonymous memory" -- mmap(MAP_ANONYMOUS | MAP_PRIVATE) -- is usually completely managed using the process page tables. The only way to get such pages mapped into another process is via fork(), whereby page table are copied and COW (Copy On Write) applies.

Once dereferenced from all page tables, there are no other references anymore; memory is handed back to the buddy as free memory, from where it can be reused for other purposes. Of course, there are case where there might be other references being taken (i.e., GUP, direct I/O ...), but let's ignore that for now.

The essence for "private anonymous memory" is, that there is no other way to get access to that memory besides the page tables. If you MADV_DONTNEED virtual memory regions to zap the page table entries and later reaccess the same virtual memory locations, always fresh memory will be populated.


"shared anonymous memory" -- mmap(MAP_ANONYMOUS | MAP_SHARED) -- is a little different and involves the page cache (it's pretty much shmem without a user-visible fd). The only way to get such pages mapped into another process is similarly via fork() (AFAIU), whereby page table are copied and COW does _not_ apply.

Once dereferenced from all page tables, there is still a reference to the page from the page cache. Only once evicted from the page cache, the memory can be freed up.

The essence for "shared anonymous memory" is, that there are ways to get access to that memory besides the page tables. If you MADV_DONTNEED such virtual memory locations to zap the page table entries and later reaccess the same virtual memory location again, the previous page will be re-instantiated from the page cache. To evict the pages from the page cache you would need MADV_REMOVE.

--
Thanks,

David / dhildenb






[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux