LKML Archive on
help / color / mirror / Atom feed
From: Paul Mundt <>
To: Andrew Morton <>
Cc: David Rientjes <>,
	Hugh Dickins <>,
	Christoph Lameter <>,
Subject: Re: [patch 1/3 take2] smaps: extract pte walker from smaps code
Date: Wed, 7 Feb 2007 16:24:55 +0900	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Tue, Feb 06, 2007 at 10:49:14PM -0800, Andrew Morton wrote:
> On Wed, 7 Feb 2007 15:29:34 +0900 Paul Mundt <> wrote:
> > I like the general idea of this patch set, however..
> David didn't really spell out the rationale.  Userspace people ask "how
> much memory is my application using".  For system planning and such.  We
> don't know, really.  So the approach taken here is to nuke all the
> referenced bits and to then monitor them coming back over time.
> Obviously it doesn't work very well if the page scanner is doing things,
> but one hopes that when someone is instrumenting their application they'll
> ensure that sufficient memory is available to prevent this inaccuracy.
This was the problem we kept running in to as well, people that wanted to
instrument their applications on the desktop where all of the required
infrastructure already brought the system to its knees long before
instrumentation could begin didn't really provide the most consistent
metrics, especially when the application depended heavily on overcommit.

This resulted in a lot of extra hacks on top of the smaps code trying to
balance out the numbers, this just ended up being a massive headache.
smaps seems to be an appealing target for piling additional semantics on,

> I don't really have a sense for how much stuff we want to put into the kernel
> to support this sort of thing.  The proposed patches are, I think, minimal.
> Perhaps it needs more.  If so, opinions are solicited before we go and add
> (and hence be forced to maintain) this new interface.
This sort of minimalist interface is not necessarily a bad approach if it
helps in a way that works for the people that really want it. The issue
with any of the smaps extensions is being able to provide people with a
"good enough" metric without falling in to interface hell. This really
depends on how one defines "good enough", though. It would be nice to
hear from application folks if this ends up being useful for them or not.

> > Perhaps this is something that needs to be looked at more closely and
> > made more generic? There are many ranged page table walkers that aren't
> > so performance critical that the function call cost would cause too much
> > pain. ioremap_page_range() comes to mind, and there's bound to be others.
> > This would also help people to get the pte map/unmap right, which seems
> > to pop up from time to time as well..
> That's what Paul Davies' patches are aimed at:
> I promised Paul that I'd take a serious look at those patches next time
> they pop up.   It would be good if others could help out in that.

It would be nice to see this smaps patchset rebased on something like
that rather than introducing another walker abstraction simply to have it
overhauled later. I realize this isn't really David's problem, but we
shouldn't be trying to solve the same problem multiple times.

  reply	other threads:[~2007-02-07  7:26 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-07  6:15 David Rientjes
2007-02-07  6:15 ` [patch 2/3 take2] smaps: add pages referenced count to smaps David Rientjes
2007-02-07  6:15   ` [patch 3/3 take2] smaps: add clear_refs file to clear reference David Rientjes
2007-02-07  6:33     ` Andrew Morton
2007-02-07  6:29 ` [patch 1/3 take2] smaps: extract pte walker from smaps code Paul Mundt
2007-02-07  6:49   ` Andrew Morton
2007-02-07  7:24     ` Paul Mundt [this message]
2007-02-09  2:00   ` Matt Mackall
2007-02-09  2:25     ` David Rientjes
2007-02-07  8:30 ` Christoph Lameter
2007-02-07  9:35   ` David Rientjes
2007-02-09 16:15   ` Matt Mackall

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \
    --subject='Re: [patch 1/3 take2] smaps: extract pte walker from smaps code' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).