linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Wxz76@protonmail.com
To: willy@infradead.org
Cc: linux-mm@kvack.org, peter.weber@flapflap.eu
Subject: Re: Is anonymous memory part of the page cache on Linux?
Date: Sun, 14 Mar 2021 23:06:12 +0000	[thread overview]
Message-ID: <003301d7191e$36b035b0$a410a110$@protonmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2050 bytes --]

Hi Matthew and Peter,

I had a few questions to clarify my understanding of the page/swap cache.

> There's a swap cache, but that's not the same thing as the page cache.

My understanding of the swap cache comes from:

1) Understanding the Linux Kernel by Bovet and Cesati:

“The swap cache is implemented by the page cache data structures and procedures ” and

“Pages in the swap cache are stored as every other page in the page cache, with the following special treatment:

• The mapping field of the page descriptor is set to NULL.

• The PG_swapcache flag of the page descriptor is set.

• The private field stores the swapped-out page identifier associated with the page”

2) Understanding the Linux Virtual Memory Manager by Mel Gorman:

“The swap cache is purely conceptual because it is simply a specialization of the page cache. The first principal difference between pages in the swap cache rather than the page cache is that pages in the swap

cache always use swapper space as their address space in page→mapping. The second difference is that pages are added to the swap cache with add to swap cache(), shown in Figure 11.3, instead of add to page cache().”

I understand that those books are more than ten years old, but is what they write no longer the case?

Is the swap cache mechanism not a specialization of the page cache, and, if not, how are they different?

> Anonymous memory is not handled by the page cache.

> Anonymous pages enter the storage stack via swap; they are

> found in the page tables, sent to the swap cache and then written to

> swap devices or swap files.

This is for the case of swapping out anonymous memory, but what about anonymous memory that is allocated dynamically with malloc/mmap: where is this memory coming from?

When mmap opens files, it maps a process address spaces to a region in the page cache for the file, does it not?

Is this behavior not the same for allocating anonymous memory (minus dealing with a file)?

I appreciate the help in clarifying this for me.

wxz

[-- Attachment #2: Type: text/html, Size: 4843 bytes --]

             reply	other threads:[~2021-03-14 23:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-14 23:06 Wxz76 [this message]
2021-03-15  0:07 ` Is anonymous memory part of the page cache on Linux? Matthew Wilcox
  -- strict thread matches above, loose matches on Subject: below --
2021-03-12 14:43 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

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='003301d7191e$36b035b0$a410a110$@protonmail.com' \
    --to=wxz76@protonmail.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).