From: Matt Mackall <mpm@selenic.com>
To: Dave Hansen <haveblue@us.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org,
Rusty Russell <rusty@rustcorp.com.au>,
Jeremy Fitzhardinge <jeremy@goop.org>,
David Rientjes <rientjes@google.com>,
Fengguang Wu <wfg@mail.ustc.edu.cn>
Subject: Re: [PATCH 10/11] maps3: add /proc/kpagecount and /proc/kpageflags interfaces
Date: Mon, 15 Oct 2007 18:11:06 -0500 [thread overview]
Message-ID: <20071015231106.GX19691@waste.org> (raw)
In-Reply-To: <1192488513.6118.98.camel@localhost>
On Mon, Oct 15, 2007 at 03:48:33PM -0700, Dave Hansen wrote:
> On Mon, 2007-10-15 at 17:26 -0500, Matt Mackall wrote:
> > From: Matt Mackall <mpm@selenic.com>
> >
> > This makes physical page map counts available to userspace. Together
> > with /proc/pid/pagemap and /proc/pid/clear_refs, this can be used to
> > monitor memory usage on a per-page basis.
> ...
> > + while (count > 0) {
> > + ppage = pfn_to_page(pfn++);
> > + if (!ppage)
> > + pflags = 0;
> > + else
> > + pflags = ppage->flags;
> > +
>
> This one makes me worry a little bit. Are we sure that this won't
> expose a wee bit too much to userspace?
>
> I can see it making sense to clear the page refs, then inspect whether
> the page has been referenced again. But, I worry that people are going
> to start doing things like read NUMA, SPARSEMEM, or other internal
> information out of these.
Hmm, I would have thought you'd find the NUMA bits especially interesting.
Being able to, say, colorize a process' memory map by what nodes its
pages land on could be very telling.
> I've seen quite a few patches lately that do creative things with these
> *cough*clameter*cough*, and I worry that they're too fluid to get
> exposed to userspace.
That is a concern. In general, I think getting too cute with page
flags and struct page in general is a bad idea because the rules here
are already so complex/fragile/confusing/underdocumented, but there's
definitely a lot of pressure in that direction.
> Could we just have /proc/kpagereferenced? Is there a legitimate need
> for other flags to be visible?
Referenced, dirty, uptodate, lru, active, slab, writeback, reclaim,
and buddy all look like they might be interesting to me from the point
of view of watching what's happening in the VM graphically in
real-time.
For instance, watching the slab bit I can watch a 'find /' fill up
huge swaths of contiguous dcache memory, then get fragmented to hell
and never recover when I do a large userspace malloc. In other words,
this thing actually lets you see all the crap that happens in the VM
that we usually handwave about.
--
Mathematics is the supreme nostalgia of our time.
next prev parent reply other threads:[~2007-10-15 23:11 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-15 22:25 [PATCH 0/11] maps3: pagemap monitoring v3 Matt Mackall
2007-10-15 22:25 ` [PATCH 1/11] maps3: add proportional set size accounting in smaps Matt Mackall
2007-10-15 23:36 ` David Rientjes
2007-10-16 0:18 ` Matt Mackall
2007-10-16 2:24 ` David Rientjes
2007-10-15 22:25 ` [PATCH 2/11] maps3: introduce task_size_of for all arches Matt Mackall
2007-10-15 23:45 ` David Rientjes
2007-10-16 0:36 ` Dave Hansen
2007-10-16 2:26 ` David Rientjes
2007-10-16 17:18 ` maps3: introduce task_size_of for all arches (updated v4) Dave Hansen
2007-10-16 17:25 ` David Rientjes
2007-10-15 22:26 ` [PATCH 3/11] maps3: move is_swap_pte Matt Mackall
2007-10-15 22:26 ` [PATCH 4/11] maps3: introduce a generic page walker Matt Mackall
2007-10-15 22:40 ` Jeremy Fitzhardinge
2007-10-15 23:05 ` Dave Hansen
2007-10-15 23:20 ` Jeremy Fitzhardinge
2007-10-15 23:30 ` Matt Mackall
2007-10-16 4:58 ` David Rientjes
2007-10-15 22:26 ` [PATCH 5/11] maps3: use pagewalker in clear_refs and smaps Matt Mackall
2007-10-16 5:03 ` David Rientjes
2007-10-15 22:26 ` [PATCH 6/11] maps3: simplify interdependence of maps " Matt Mackall
2007-10-15 22:26 ` [PATCH 7/11] maps3: move clear_refs code to task_mmu.c Matt Mackall
2007-10-16 5:11 ` David Rientjes
2007-10-15 22:26 ` [PATCH 8/11] maps3: regroup task_mmu by interface Matt Mackall
2007-10-15 22:26 ` [PATCH 9/11] maps3: add /proc/pid/pagemap interface Matt Mackall
2007-10-15 22:26 ` [PATCH 10/11] maps3: add /proc/kpagecount and /proc/kpageflags interfaces Matt Mackall
2007-10-15 22:48 ` Dave Hansen
2007-10-15 23:11 ` Matt Mackall [this message]
2007-10-15 23:34 ` Dave Hansen
2007-10-16 0:35 ` Matt Mackall
2007-10-16 0:49 ` Dave Hansen
2007-10-16 0:58 ` Matt Mackall
2007-10-16 1:07 ` Dave Hansen
2007-10-15 22:26 ` [PATCH 11/11] maps3: make page monitoring /proc file optional Matt Mackall
2007-10-15 22:49 ` Dave Hansen
2007-10-15 22:51 ` Jeremy Fitzhardinge
2007-10-16 0:03 ` Rusty Russell
2007-10-16 0:20 ` Matt Mackall
2007-10-16 5:25 ` David Rientjes
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=20071015231106.GX19691@waste.org \
--to=mpm@selenic.com \
--cc=akpm@linux-foundation.org \
--cc=haveblue@us.ibm.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rientjes@google.com \
--cc=rusty@rustcorp.com.au \
--cc=wfg@mail.ustc.edu.cn \
/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