LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org> To: Paul Mundt <lethal@linux-sh.org> Cc: David Rientjes <rientjes@google.com>, Hugh Dickins <hugh@veritas.com>, Christoph Lameter <clameter@sgi.com>, linux-kernel@vger.kernel.org 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: <20070206224914.f1da7019.akpm@linux-foundation.org> (raw) In-Reply-To: <20070207062934.GA11967@linux-sh.org> On Wed, 7 Feb 2007 15:29:34 +0900 Paul Mundt <lethal@linux-sh.org> 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: http://marc.theaimsgroup.com/?l=linux-mm&m=115276500100695&w=2 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.
next prev parent 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: 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=20070206224914.f1da7019.akpm@linux-foundation.org \ --to=akpm@linux-foundation.org \ --cc=clameter@sgi.com \ --cc=hugh@veritas.com \ --cc=lethal@linux-sh.org \ --cc=linux-kernel@vger.kernel.org \ --cc=rientjes@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: linkBe 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).