[PATCH v2 0/1] Documenting shmem as an exception case for the pagemap

[PATCH v2 0/1] Documenting shmem as an exception case for the pagemap

[Tiberiu A Georgescu]

This patch follows the discussions on a previous documentation patch
thread [1]. It presents the exception case of shared memory management from
the pagemap's point of view. It briefly describes what is missing, why it
is missing and alternatives to the pagemap for swap info retrieval.

In short, the kernel does not keep track of PTEs for shared pages within
the processes that references them. Thus, the proc/pid/pagemap tool cannot
print the swap destination of the shared memory pages, instead setting the
pagemap entry to zero for both non-allocated and swapped out pages. This
can create confusion for users who need information on swapped out pages.

The reasons why maintaining the PTEs of all swapped out shared pages among
all processes while maintaining similar performance is not a trivial task,
or a desirable change have been discussed extensively [1][2][3][4]. There
are also arguments for why this arguably missing information should be
exposed to the user in either a future pagemap patch, or an alternative.

[1]: https://marc.info/?m=162878395426774
[2]: https://lore.kernel.org/lkml/20210730160826.63785-1-tiberiu.georgescu@nutanix.com/
[3]: https://lore.kernel.org/lkml/20210807032521.7591-1-peterx@redhat.com/
[4]: https://lore.kernel.org/lkml/20210715201651.212134-1-peterx@redhat.com/

Kind regards,
Tibi

Tiberiu A Georgescu (1):
  Documentation: update pagemap with shmem exceptions

 Documentation/admin-guide/mm/pagemap.rst | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

-- 
2.33.0.363.g4c719308ce

[PATCH v2 1/1] Documentation: update pagemap with shmem exceptions

[Tiberiu A Georgescu]

Mentioning the current missing information in the pagemap and alternatives
on how to retrieve it, in case someone stumbles upon unexpected behaviour.

Signed-off-by: Tiberiu A Georgescu <tiberiu.georgescu@nutanix.com>
Reviewed-by: Ivan Teterevkov <ivan.teterevkov@nutanix.com>
Reviewed-by: Florian Schmidt <florian.schmidt@nutanix.com>
Reviewed-by: Carl Waldspurger <carl.waldspurger@nutanix.com>
Reviewed-by: Jonathan Davies <jonathan.davies@nutanix.com>
---
 Documentation/admin-guide/mm/pagemap.rst | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/Documentation/admin-guide/mm/pagemap.rst b/Documentation/admin-guide/mm/pagemap.rst
index fb578fbbb76c..ea3f88f3c18d 100644
--- a/Documentation/admin-guide/mm/pagemap.rst
+++ b/Documentation/admin-guide/mm/pagemap.rst
@@ -196,6 +196,28 @@ you can go through every map in the process, find the PFNs, look those up
 in kpagecount, and tally up the number of pages that are only referenced
 once.
 
+Exceptions for Shared Memory
+============================
+
+Page table entries for shared pages are cleared when the pages are zapped or
+swapped out. This makes swapped out pages indistinguishable from never-allocated
+ones.
+
+In kernel space, the swap location can still be retrieved from the page cache.
+However, values stored only on the normal PTE get lost irretrievably when the
+page is swapped out (i.e. SOFT_DIRTY).
+
+In user space, whether the page is swapped or none can be deduced with the
+lseek system call. For a single page, the algorithm is:
+
+0. If the pagemap entry of the page has bit 63 (page present) set, the page
+   is present.
+1. Otherwise, get an fd to the file where the page is backed. For anonymous
+   shared pages, the file can be found in ``/proc/pid/map_files/``.
+2. Call lseek with LSEEK_DATA flag and seek to the virtual address of the page
+   you wish to inspect. If it overshoots the PAGE_SIZE, the page is NONE.
+3. Otherwise, the page is in swap.
+
 Other notes
 ===========
 
-- 
2.33.0.363.g4c719308ce

Re: [PATCH v2 1/1] Documentation: update pagemap with shmem exceptions

[David Hildenbrand]

On 20.09.21 18:49, Tiberiu A Georgescu wrote:
> Mentioning the current missing information in the pagemap and alternatives
> on how to retrieve it, in case someone stumbles upon unexpected behaviour.
> 
> Signed-off-by: Tiberiu A Georgescu <tiberiu.georgescu@nutanix.com>
> Reviewed-by: Ivan Teterevkov <ivan.teterevkov@nutanix.com>
> Reviewed-by: Florian Schmidt <florian.schmidt@nutanix.com>
> Reviewed-by: Carl Waldspurger <carl.waldspurger@nutanix.com>
> Reviewed-by: Jonathan Davies <jonathan.davies@nutanix.com>
> ---
>   Documentation/admin-guide/mm/pagemap.rst | 22 ++++++++++++++++++++++
>   1 file changed, 22 insertions(+)
> 
> diff --git a/Documentation/admin-guide/mm/pagemap.rst b/Documentation/admin-guide/mm/pagemap.rst
> index fb578fbbb76c..ea3f88f3c18d 100644
> --- a/Documentation/admin-guide/mm/pagemap.rst
> +++ b/Documentation/admin-guide/mm/pagemap.rst
> @@ -196,6 +196,28 @@ you can go through every map in the process, find the PFNs, look those up
>   in kpagecount, and tally up the number of pages that are only referenced
>   once.
>   
> +Exceptions for Shared Memory
> +============================
> +
> +Page table entries for shared pages are cleared when the pages are zapped or
> +swapped out. This makes swapped out pages indistinguishable from never-allocated
> +ones.
> +
> +In kernel space, the swap location can still be retrieved from the page cache.
> +However, values stored only on the normal PTE get lost irretrievably when the
> +page is swapped out (i.e. SOFT_DIRTY).
> +
> +In user space, whether the page is swapped or none can be deduced with the
> +lseek system call. For a single page, the algorithm is:
> +
> +0. If the pagemap entry of the page has bit 63 (page present) set, the page
> +   is present.
> +1. Otherwise, get an fd to the file where the page is backed. For anonymous
> +   shared pages, the file can be found in ``/proc/pid/map_files/``.
> +2. Call lseek with LSEEK_DATA flag and seek to the virtual address of the page
> +   you wish to inspect. If it overshoots the PAGE_SIZE, the page is NONE.
> +3. Otherwise, the page is in swap.
> +
>   Other notes
>   ===========
>   
> 

Thanks!

Reviewed-by: David Hildenbrand <david@redhat.com>

-- 
Thanks,

David / dhildenb

Re: [PATCH v2 1/1] Documentation: update pagemap with shmem exceptions

[Peter Xu]

Hi, Tiberiu,

Thanks for the patch!  Yes it would still be nice to comment on this behavior,
some trivial nitpicks below.

On Mon, Sep 20, 2021 at 04:49:31PM +0000, Tiberiu A Georgescu wrote:
> +In user space, whether the page is swapped or none can be deduced with the
> +lseek system call. For a single page, the algorithm is:
> +
> +0. If the pagemap entry of the page has bit 63 (page present) set, the page
> +   is present.
> +1. Otherwise, get an fd to the file where the page is backed. For anonymous
> +   shared pages, the file can be found in ``/proc/pid/map_files/``.
> +2. Call lseek with LSEEK_DATA flag and seek to the virtual address of the page

s/LSEEK_DATA/SEEK_DATA/

> +   you wish to inspect. If it overshoots the PAGE_SIZE, the page is NONE.
> +3. Otherwise, the page is in swap.

It could also not be in swap, right?

Example 1: this process mmap()ed an existing shmem file with data filled in,
but without accessing it yet.  Then the page cache exists, not in swap, but
pgtables will be empty.

Example 2: this process has mapped this shmem with 2M thp, all data filled in,
then due to some reason thp splits, then the pgtable can also be none but lseek
will succeed, I think.

So to further identify whether that's in swap, we need a step 5 with mincore()
system call, perhaps?

-- 
Peter Xu

Re: [PATCH v2 1/1] Documentation: update pagemap with shmem exceptions

[Tiberiu Georgescu]

> On 20 Sep 2021, at 20:07, Peter Xu <peterx@redhat.com> wrote:
> 
> Hi, Tiberiu,
> 
> Thanks for the patch!  Yes it would still be nice to comment on this behavior,
> some trivial nitpicks below.
> 
> On Mon, Sep 20, 2021 at 04:49:31PM +0000, Tiberiu A Georgescu wrote:
>> +In user space, whether the page is swapped or none can be deduced with the
>> +lseek system call. For a single page, the algorithm is:
>> +
>> +0. If the pagemap entry of the page has bit 63 (page present) set, the page
>> +   is present.
>> +1. Otherwise, get an fd to the file where the page is backed. For anonymous
>> +   shared pages, the file can be found in ``/proc/pid/map_files/``.
>> +2. Call lseek with LSEEK_DATA flag and seek to the virtual address of the page
> 
> s/LSEEK_DATA/SEEK_DATA/

Oops, mb. Will change that.
> 
>> +   you wish to inspect. If it overshoots the PAGE_SIZE, the page is NONE.
>> +3. Otherwise, the page is in swap.
> 
> It could also not be in swap, right?
> 
> Example 1: this process mmap()ed an existing shmem file with data filled in,
> but without accessing it yet.  Then the page cache exists, not in swap, but
> pgtables will be empty.
> 
> Example 2: this process has mapped this shmem with 2M thp, all data filled in,
> then due to some reason thp splits, then the pgtable can also be none but lseek
> will succeed, I think.
> 
Ok, those are a lot of exceptions. So it's possible for the pagemap entry to be
empty, yet the page itself to be actually present. When that happens, the page is
mistakenly considered in "swap" by the current algorithm.

Thanks a lot for pointing that out!

> So to further identify whether that's in swap, we need a step 5 with mincore()
> system call, perhaps?

I tested it some more, and it still looks like the mincore() syscall considers pages
in the swap cache as "in memory". This is how I tested:

1. Create a cgroup with 1M limit_in_bytes, and allow swapping
2. mmap 1024 pages (both shared and private present the same behaviour)
3. write to all pages in order
4. compare mincore output with pagemap output

This is an example of a usual mincore output in this scenario, shortened for
coherency (4x8 instead of 16x64):
00000000
00000000
00001110   <- this bugs me
01111111

The last 7 bits are definitely marking pages present in memory, but there are
some other bits set a little earlier. When comparing this output with the pagemap,
indeed, there are 7 consecutive pages present, and the rest of them are
swapped, including those 3 which are marked as present by mincore.
At this point, I can only assume the bits in between are on the swap cache.

If you have another explanation, please share it with me. In the meanwhile,
I will rework the doc patch, and see if there is any other way to differentiate
clearly between the three types of pages. If not, I guess we'll stick to
mincore() and a best-effort 5th step.

--
Kind regards,
Tibi

Re: [PATCH v2 1/1] Documentation: update pagemap with shmem exceptions

[Peter Xu]

Hi, Tiberiu,

On Tue, Sep 21, 2021 at 08:52:32AM +0000, Tiberiu Georgescu wrote:
> I tested it some more, and it still looks like the mincore() syscall considers pages
> in the swap cache as "in memory". This is how I tested:
> 
> 1. Create a cgroup with 1M limit_in_bytes, and allow swapping
> 2. mmap 1024 pages (both shared and private present the same behaviour)
> 3. write to all pages in order
> 4. compare mincore output with pagemap output
> 
> This is an example of a usual mincore output in this scenario, shortened for
> coherency (4x8 instead of 16x64):
> 00000000
> 00000000
> 00001110   <- this bugs me
> 01111111
> 
> The last 7 bits are definitely marking pages present in memory, but there are
> some other bits set a little earlier. When comparing this output with the pagemap,
> indeed, there are 7 consecutive pages present, and the rest of them are
> swapped, including those 3 which are marked as present by mincore.
> At this point, I can only assume the bits in between are on the swap cache.
> 
> If you have another explanation, please share it with me. In the meanwhile,
> I will rework the doc patch, and see if there is any other way to differentiate
> clearly between the three types of pages. If not, I guess we'll stick to
> mincore() and a best-effort 5th step.

IIUC it could be because of that the pages are still in swap cache, so
mincore() will return 1 for them too.

What swap device are you using?  I'm wildly guessing you're not using frontswap
like zram.  If that's the case, would you try zram?  That should flush the page
synchronously iiuc, then all the "suspecious 1s" will go away above.

To do that, you may need to firstly turn off your current swap:

        # swapoff -a

Then to configure zram you need:

        # modprobe zram
        # echo 4G > /sys/block/zram0/disksize
        # mkswap --label zram0 /dev/zram0
        # swapon --priority 100 /dev/zram0

Quotting from here:

        https://wiki.archlinux.org/title/Improving_performance#zram_or_zswap

Then you can try run the same test program again.

Thanks,

-- 
Peter Xu

Re: [PATCH v2 1/1] Documentation: update pagemap with shmem exceptions

[Tiberiu Georgescu]

> On 21 Sep 2021, at 16:04, Peter Xu <peterx@redhat.com> wrote:
> 
> Hi, Tiberiu,
> 
> On Tue, Sep 21, 2021 at 08:52:32AM +0000, Tiberiu Georgescu wrote:
>> I tested it some more, and it still looks like the mincore() syscall considers pages
>> in the swap cache as "in memory". This is how I tested:
>> 
>> 1. Create a cgroup with 1M limit_in_bytes, and allow swapping
>> 2. mmap 1024 pages (both shared and private present the same behaviour)
>> 3. write to all pages in order
>> 4. compare mincore output with pagemap output
>> 
>> This is an example of a usual mincore output in this scenario, shortened for
>> coherency (4x8 instead of 16x64):
>> 00000000
>> 00000000
>> 00001110   <- this bugs me
>> 01111111
>> 
>> The last 7 bits are definitely marking pages present in memory, but there are
>> some other bits set a little earlier. When comparing this output with the pagemap,
>> indeed, there are 7 consecutive pages present, and the rest of them are
>> swapped, including those 3 which are marked as present by mincore.
>> At this point, I can only assume the bits in between are on the swap cache.
>> 
>> If you have another explanation, please share it with me. In the meanwhile,
>> I will rework the doc patch, and see if there is any other way to differentiate
>> clearly between the three types of pages. If not, I guess we'll stick to
>> mincore() and a best-effort 5th step.
> 
> IIUC it could be because of that the pages are still in swap cache, so
> mincore() will return 1 for them too.

That is my assumption as well.
> 
> What swap device are you using?  I'm wildly guessing you're not using frontswap
> like zram.  If that's the case, would you try zram?  That should flush the page
> synchronously iiuc, then all the "suspecious 1s" will go away above.

Correct, I was not using frontswap.
> 
> To do that, you may need to firstly turn off your current swap:
> 
>        # swapoff -a
> 
> Then to configure zram you need:
> 
>        # modprobe zram
>        # echo 4G > /sys/block/zram0/disksize
>        # mkswap --label zram0 /dev/zram0
>        # swapon --priority 100 /dev/zram0
> 
> Quotting from here:
> 
>        https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.archlinux.org_title_Improving-5Fperformance-23zram-5For-5Fzswap&d=DwIBaQ&c=s883GpUCOChKOHiocYtGcg&r=rRM5dtWOv0DNo5dDxZ2U16jl4WAw6ql5szOKa9cu_RA&m=XWzLVqSSl8CSEcw2x6sUmspJhiUJei2gq6GTiaky8hk&s=k3BDgO9LN63Nn3vxorlc41MlUYzOUN0efajz4lol-k8&e= 
> 
> Then you can try run the same test program again.

Thanks, it worked!

Hmmm, so if we put emphasis on the accuracy of swap info, or accuracy in
general, we need to use frontswap. Otherwise, mincore() could suffer from
race conditions, and mark pages in the swap cache as being present.

Do you reckon this info (frontswap for mincore) should be present in
the pagemap docs? I wouldn't want to bloat the section either.

Kind regards,
Tibi

Re: [PATCH v2 1/1] Documentation: update pagemap with shmem exceptions

[Peter Xu]

On Tue, Sep 21, 2021 at 04:08:29PM +0000, Tiberiu Georgescu wrote:
> Hmmm, so if we put emphasis on the accuracy of swap info, or accuracy in
> general, we need to use frontswap. Otherwise, mincore() could suffer from
> race conditions, and mark pages in the swap cache as being present.

IMHO it's not a race condition, but by design.

Quotting again from the mincore() man page:

       The vec argument must point to an array containing at least
       (length+PAGE_SIZE-1) / PAGE_SIZE bytes.  On return, the least
       significant bit of each byte will be set if the corresponding page is
       currently resident in memory, and be clear otherwise.

I think "within swap cache" does mean that it still resides in memory, so it's
not violating what it's designed to me, at least from the manpage.

> 
> Do you reckon this info (frontswap for mincore) should be present in
> the pagemap docs? I wouldn't want to bloat the section either.

I don't think the type of swap matters in this document, but imho mentioning
mincore() as the alternative to fetch swap is still meaningful as that's what's
missing for pagemap right now on shmem typed memories.

Even if it cannot identify some cases between "page presents", "page stays in
page cache", or "page stays in swap cache", it'll still be good enough to me.

Thanks,

-- 
Peter Xu

Re: [PATCH v2 1/1] Documentation: update pagemap with shmem exceptions

[Tiberiu Georgescu]

> On 21 Sep 2021, at 17:30, Peter Xu <peterx@redhat.com> wrote:
> 
> On Tue, Sep 21, 2021 at 04:08:29PM +0000, Tiberiu Georgescu wrote:
>> Hmmm, so if we put emphasis on the accuracy of swap info, or accuracy in
>> general, we need to use frontswap. Otherwise, mincore() could suffer from
>> race conditions, and mark pages in the swap cache as being present.
> 
> IMHO it's not a race condition, but by design.
> 
> Quotting again from the mincore() man page:
> 
>       The vec argument must point to an array containing at least
>       (length+PAGE_SIZE-1) / PAGE_SIZE bytes.  On return, the least
>       significant bit of each byte will be set if the corresponding page is
>       currently resident in memory, and be clear otherwise.
> 
> I think "within swap cache" does mean that it still resides in memory, so it's
> not violating what it's designed to me, at least from the manpage.

I agree mincore() is doing what it is designed to do. I did not express my
thoughts correctly.
> 
>> 
>> Do you reckon this info (frontswap for mincore) should be present in
>> the pagemap docs? I wouldn't want to bloat the section either.
> 
> I don't think the type of swap matters in this document, but imho mentioning
> mincore() as the alternative to fetch swap is still meaningful as that's what's
> missing for pagemap right now on shmem typed memories.
> 
> Even if it cannot identify some cases between "page presents", "page stays in
> page cache", or "page stays in swap cache", it'll still be good enough to me.

Yeah, it should be good enough mostly. But I feel that providing an exact
algorithm on how to separate the cases is not appropriate anymore,
as there are still exceptions, and the "perfect" algorithm needs frontswap
as a backend, which can be a fairly prohibitive precondition.

Maybe I should just note all these tools down instead and provide a brief
explanation of their usage and their downsides in the context of pagemap
information.

Thanks a lot for all suggestions! I'll cook up a v3 shortly.

Kind regards,
Tibi