[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1192488513.6118.98.camel@localhost>
Date: Mon, 15 Oct 2007 15:48:33 -0700
From: Dave Hansen <haveblue@...ibm.com>
To: Matt Mackall <mpm@...enic.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org,
Rusty Russell <rusty@...tcorp.com.au>,
Jeremy Fitzhardinge <jeremy@...p.org>,
David Rientjes <rientjes@...gle.com>,
Fengguang Wu <wfg@...l.ustc.edu.cn>
Subject: Re: [PATCH 10/11] maps3: add /proc/kpagecount and /proc/kpageflags
interfaces
On Mon, 2007-10-15 at 17:26 -0500, Matt Mackall wrote:
> From: Matt Mackall <mpm@...enic.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.
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.
Could we just have /proc/kpagereferenced? Is there a legitimate need
for other flags to be visible?
-- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists