From: David Hildenbrand <david@redhat.com>
To: Mina Almasry <almasrymina@google.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 12:42:40 +0100 [thread overview]
Message-ID: <9fd0a86f-c012-4bb7-78eb-7413346448e0@redhat.com> (raw)
In-Reply-To: <CAHS8izOkvuZ2pEGZXaYb0mfwC3xwpvXSgc9S+u_R-0zLWjzznQ@mail.gmail.com>
>> 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.
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.
We could separate the cases "cont PTE huge page" vs. "PMD huge page".
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
next prev parent reply other threads:[~2021-11-02 11:42 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 [this message]
2021-11-02 18:38 ` Mina Almasry
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=9fd0a86f-c012-4bb7-78eb-7413346448e0@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=almasrymina@google.com \
--cc=corbet@lwn.net \
--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).