linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mina Almasry <almasrymina@google.com>
To: David Hildenbrand <david@redhat.com>
Cc: Nathan Lewis <npl@google.com>, Yu Zhao <yuzhao@google.com>,
	"Paul E . McKenney" <paulmckrcu@fb.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	Peter Xu <peterx@redhat.com>,
	Ivan Teterevkov <ivan.teterevkov@nutanix.com>,
	Florian Schmidt <florian.schmidt@nutanix.com>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [PATCH v1] mm: Add /proc/$PID/pageflags
Date: Tue, 2 Nov 2021 11:38:23 -0700	[thread overview]
Message-ID: <CAHS8izOrwiUrMD=QYjpda3trMkHLaK4UuAee_zvnmPj1h6Lycg@mail.gmail.com> (raw)
In-Reply-To: <9fd0a86f-c012-4bb7-78eb-7413346448e0@redhat.com>

On Tue, Nov 2, 2021 at 4:42 AM David Hildenbrand <david@redhat.com> wrote:
>
> >> Bit 58-60 are still free, no? Bit 57 was recently added for uffd-wp
> >> purposes I think.
> >>
> >> #define PM_SOFT_DIRTY           BIT_ULL(55)
> >> #define PM_MMAP_EXCLUSIVE       BIT_ULL(56)
> >> #define PM_UFFD_WP              BIT_ULL(57)
> >> #define PM_FILE                 BIT_ULL(61)
> >> #define PM_SWAP                 BIT_ULL(62)
> >> #define PM_PRESENT              BIT_ULL(63)
> >>
> >> PM_MMAP_EXCLUSIVE and PM_FILE already go into the direction of "what is
> >> mapped" IMHO. So just a thought if something in there (PM_HUGE? PM_THP?)
> >> ... could make sense.
> >>
> >
> > Thanks! I _think_ that would work for us, I'll look into confirming.
> > To be honest I still wonder if eventually different folks will find
> > uses for other page flags and eventually we'll run out of pagemaps
> > bits, but I'll yield to whatever you think is best here.
>
> Using one of the remaining 3 bits should be fine. In the worst case,
> we'll need pagemap_ext at some point that provides more bits per PFN, if
> we ever run out of bits.
>

That sounds great to me. Thank you Both Matthew and David for
patiently explaining the concerns with /proc/self/pageflags to me and
suggesting alternatives that could work :-)

> But as mentioned by Matthew, extending mincore() could also work: not
> only indicating if the page is resident, but also in which "form" it is
> resident.
>

I need to learn more about mincore() to be honest, from casually
reading some docs I didn't get a full understanding on if/why that
would work better. I'll do some investigating and upload V2 either
with /proc/self/pagemaps or mincore() and why I chose such and we can
go from there.

> We could separate the cases "cont PTE huge page" vs. "PMD huge page".
>

So to be completely honest (and I need to confirm), we are using this
on x86 and we essentially care that the virt address is mapped by 2MB,
so mapped by PMD. I think (but need to confirm) that's what the
pageflags HUGE bit refers to as well as does PageHuge() and
TransPageHuge(). After confirming I'll upload V2 with the precise info
we need (I think it's going to be "PMD huge page" as David says).

> I recall that the information (THP / !THP) might be valuable for users:
> there was a discussion to let user space decide where to place THP.
> (IIRC madvise() extension to have something like MADV_COLLAPSE_THP /
> MADV_DISSOLVE_THP)
>
> --
> Thanks,
>
> David / dhildenb
>

      reply	other threads:[~2021-11-02 18:38 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-28 20:58 [PATCH v1] mm: Add /proc/$PID/pageflags Mina Almasry
2021-10-29  7:11 ` David Hildenbrand
2021-10-29 20:04   ` Mina Almasry
2021-10-29 21:37     ` David Hildenbrand
2021-10-30 22:06       ` Mina Almasry
2021-10-31  2:28         ` Matthew Wilcox
2021-11-02 11:42         ` David Hildenbrand
2021-11-02 18:38           ` Mina Almasry [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='CAHS8izOrwiUrMD=QYjpda3trMkHLaK4UuAee_zvnmPj1h6Lycg@mail.gmail.com' \
    --to=almasrymina@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=corbet@lwn.net \
    --cc=david@redhat.com \
    --cc=florian.schmidt@nutanix.com \
    --cc=ivan.teterevkov@nutanix.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=npl@google.com \
    --cc=paulmckrcu@fb.com \
    --cc=peterx@redhat.com \
    --cc=yuzhao@google.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).