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

On Wed, 7 Feb 2007 15:29:34 +0900 Paul Mundt <> wrote:

> On Tue, Feb 06, 2007 at 10:15:47PM -0800, David Rientjes wrote:
> > Extracts the page table entry walker from the smaps-specific code in
> > fs/proc/task_mmu.c.  This will be used later for clearing the reference
> > bits on pages to measure the number of pages accessed over a time period
> > through /proc/pid/smaps.
> > 
> 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.

The other part of the question is of course pagecache.  Hopefully /proc/pid/io
will suffice for that, probably in combination with /proc/sys/vm/drop_caches.

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.

> > Since the PTE walker is now extracted from the smaps code,
> > smaps_pte_func() is invoked for each PTE in the VMA.  Its behavior is
> > identical to the existing implementation, except it is slightly slower
> > because each PTE now invokes a function call.
> > 
> 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.

  reply	other threads:[~2007-02-07  6:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-07  6:15 [patch 1/3 take2] smaps: extract pte walker from smaps code 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 [this message]
2007-02-07  7:24     ` Paul Mundt
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 \ \ \ \ \ \ \ \

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