From: David Hildenbrand <david@redhat.com>
To: Matthew Wilcox <willy@infradead.org>,
Peter Weber <peter.weber@flapflap.eu>
Cc: linux-mm@kvack.org
Subject: Re: Is anonymous memory part of the page cache on Linux?
Date: Wed, 17 Mar 2021 14:42:58 +0100 [thread overview]
Message-ID: <af7f036d-a131-985f-edd7-2ab93353b373@redhat.com> (raw)
In-Reply-To: <20210312224537.GF2577561@casper.infradead.org>
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
next prev parent reply other threads:[~2021-03-17 13:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-12 14:43 Is anonymous memory part of the page cache on Linux? Peter Weber
2021-03-12 15:15 ` Matthew Wilcox
2021-03-12 15:41 ` Peter Weber
2021-03-12 22:45 ` Matthew Wilcox
2021-03-17 13:42 ` David Hildenbrand [this message]
2021-03-14 23:06 Wxz76
2021-03-15 0:07 ` Matthew Wilcox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=af7f036d-a131-985f-edd7-2ab93353b373@redhat.com \
--to=david@redhat.com \
--cc=linux-mm@kvack.org \
--cc=peter.weber@flapflap.eu \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).