linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Tiberiu Georgescu <tiberiu.georgescu@nutanix.com>
To: Peter Xu <peterx@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Jonathan Corbet <corbet@lwn.net>,
	"david@redhat.com" <david@redhat.com>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Ivan Teterevkov <ivan.teterevkov@nutanix.com>,
	Florian Schmidt <flosch@nutanix.com>,
	"Carl Waldspurger [C]" <carl.waldspurger@nutanix.com>,
	Jonathan Davies <jond@nutanix.com>
Subject: Re: [PATCH v2 1/1] Documentation: update pagemap with shmem exceptions
Date: Tue, 21 Sep 2021 17:09:48 +0000	[thread overview]
Message-ID: <B110C852-5688-4A40-A7C8-099638D10AB7@nutanix.com> (raw)
In-Reply-To: <YUoIk247W1Sbt6Lf@t490s>


> 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



      reply	other threads:[~2021-09-21 17:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-20 16:49 [PATCH v2 0/1] Documenting shmem as an exception case for the pagemap Tiberiu A Georgescu
2021-09-20 16:49 ` [PATCH v2 1/1] Documentation: update pagemap with shmem exceptions Tiberiu A Georgescu
2021-09-20 17:36   ` David Hildenbrand
2021-09-20 19:07   ` Peter Xu
2021-09-21  8:52     ` Tiberiu Georgescu
2021-09-21 15:04       ` Peter Xu
2021-09-21 16:08         ` Tiberiu Georgescu
2021-09-21 16:30           ` Peter Xu
2021-09-21 17:09             ` Tiberiu Georgescu [this message]

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=B110C852-5688-4A40-A7C8-099638D10AB7@nutanix.com \
    --to=tiberiu.georgescu@nutanix.com \
    --cc=akpm@linux-foundation.org \
    --cc=carl.waldspurger@nutanix.com \
    --cc=corbet@lwn.net \
    --cc=david@redhat.com \
    --cc=flosch@nutanix.com \
    --cc=ivan.teterevkov@nutanix.com \
    --cc=jond@nutanix.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=peterx@redhat.com \
    /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).