linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Mina Almasry <almasrymina@google.com>
Cc: 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: Fri, 29 Oct 2021 09:11:20 +0200	[thread overview]
Message-ID: <2fede4d2-9d82-eac9-002b-9a7246b2c3f8@redhat.com> (raw)
In-Reply-To: <20211028205854.830200-1-almasrymina@google.com>

On 28.10.21 22:58, Mina Almasry wrote:
> From: Yu Zhao <yuzhao@google.com>
> 
> This file lets a userspace process know the page flags of each of its virtual
> pages.  It contains a 64-bit set of flags for each virtual page, containing
> data identical to that emitted by /proc/kpageflags.  This allows the user-space
> task can learn the kpageflags for the pages backing its address-space by
> consulting one file, without needing to be root.
> 
> Example use case is a performance sensitive user-space process querying the
> hugepage backing of its own memory without the root access required to access
> /proc/kpageflags, and without accessing /proc/self/smaps_rollup which can be
> slow and needs to hold mmap_lock.

Can you elaborate on

a) The target use case. Are you primarily interested to see if a page
given base page is head or tail?

b) Your mmap_lock comment. pagemap_read() needs to hold the mmap lock in
read mode while walking process page tables via walk_page_range().

Also, do you have a rough performance comparison?

> 
> Similar to /proc/kpageflags, the flags printed out by the kernel for
> each page are provided by stable_page_flags(), which exports flag bits
> that are user visible and stable over time.

It exports flags (documented for pageflags_read()) that are not
applicable to processes, like OFFLINE. BUDDY, SLAB, PGTABLE ... and can
never happen. Some of these kpageflags are not even page->flags, they
include abstracted types we use for physical memory pages based on other
struct page members (OFFLINE, BUDDY, MMAP, PGTABLE, ...). This feels wrong.

Also, to me it feels like we are exposing too much internal information
to the user, essentially making it ABI that user space processes will
rely on.

Did you investigate

a) Reducing the flags we expose to a bare minimum necessary for your use
case (and actually applicable to mmaped pages).

b) Extending pagemap output instead.

You seem to be interested in the "hugepage backing", which smells like
"what is mapped" as in "pagemap".


-- 
Thanks,

David / dhildenb


  reply	other threads:[~2021-10-29  7:11 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 [this message]
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

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=2fede4d2-9d82-eac9-002b-9a7246b2c3f8@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=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).