From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: William Lee Irwin III <wli@holomorphy.com>,
Matt Mackall <mpm@selenic.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/13] maps: pagemap, kpagemap, and related cleanups
Date: Fri, 13 Apr 2007 11:42:29 +1000 [thread overview]
Message-ID: <461EE005.6070605@yahoo.com.au> (raw)
In-Reply-To: <20070412182213.a18cc4a7.akpm@linux-foundation.org>
Andrew Morton wrote:
> On Fri, 13 Apr 2007 11:14:20 +1000 Nick Piggin <nickpiggin@yahoo.com.au> wrote:
>
>
>>Andrew Morton wrote:
>>>It *will* be viable. If the application wants to know if a page is dirty,
>>>it looks up "PG_dirty" in /proc/pg_foo-to-bitnumber and uses PG_dirty's
>>>numerical offset when inspecting fields in /proc/kpagemap. If correctly
>>>designed, such a monitoring application will be able to report upon page
>>>flags which we haven't even thought up yet.
>>
>>Ooh, you wanted a _runtime_ mapping of flags, yeah then I guess that works.
>>Still seems like a basically hit and miss affair to just use flags. What if
>>you want to know the process mapping a page? With systemtap or something you
>>could walk the rmap structures. What if you want to look at pages along the
>>LRU list rather than per-pfn? What about connecting pages to inodes?
>
>
> Well hang on. This isn't a tool for understanding kernel behaviour. It's
> a tool for understanding applciation behaviour.
>
> So one doesn't ask "who is mapping that page" - that's a kernel developer
> thing.
>
> Instead, one says "what pages are being used by my application", then, for
That includes unmapped pagecache being used by my application, doesn't it?
Maybe that's too hard to do via /proc so we forget about it...
> each of those pages "what is that page's state". So the first step is to
> collect all the pfns from /proc/$(pidof my-application)/pagemap and then to
> use those pfns to look the individual pages up in /proc/kpagemap.
OK I realise you could do it that way, but systemtap can definitely be
used as a tool for understanding application behaviour in the context of
the kernel, I think? The purpose for it is so that various little bits
of deep kernel internals do not have to be exposed on a case by case basis.
If kprobes is simply crappy and doesn't work properly for this, then I
could accept that. I'm not someone trying to get this info. So why can't
it be used? (not just for kpagemap, but for clear_refs and all that gunk
too).
> If you really want to know "who is using page 123435" then you'd need to
> search /proc/*/pagemap. There are possibly legitimate reasons why an
> application developer would want to at least pertially perform such an
> operation ("who am I sharing with"), but I doubt if it's the common case.
Maybe. How about LRU? Reclaim performance is bad, and you want to work out
which pages keep going off the end of it, or which pages keep getting
written out via it, or who's pages are on the active list, forcing mine
out.
--
SUSE Labs, Novell Inc.
next prev parent reply other threads:[~2007-04-13 1:42 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-04 2:43 [PATCH 0/13] maps: pagemap, kpagemap, and related cleanups Matt Mackall
2007-04-04 2:43 ` [PATCH 1/13] maps: Uninline some functions in the page walker Matt Mackall
2007-04-04 2:43 ` [PATCH 2/13] maps: Eliminate the pmd_walker struct " Matt Mackall
2007-04-04 2:43 ` [PATCH 3/13] maps: Remove vma from args " Matt Mackall
2007-04-04 2:43 ` [PATCH 4/13] maps: Propagate errors from callback in " Matt Mackall
2007-04-04 2:43 ` [PATCH 5/13] maps: Add callbacks for each level to " Matt Mackall
2007-04-04 2:43 ` [PATCH 6/13] maps: Move the page walker code to lib/ Matt Mackall
2007-04-04 3:51 ` Nick Piggin
2007-04-04 5:08 ` Matt Mackall
2007-04-04 5:50 ` Nick Piggin
2007-04-04 21:48 ` Matt Mackall
2007-04-05 1:32 ` Nick Piggin
2007-04-05 1:50 ` Nick Piggin
2007-04-04 2:43 ` [PATCH 7/13] maps: Simplify interdependence of /proc/pid/maps and smaps Matt Mackall
2007-04-04 2:43 ` [PATCH 8/13] maps: Move clear_refs code to task_mmu.c Matt Mackall
2007-04-04 2:43 ` [PATCH 9/13] maps: Regroup task_mmu by interface Matt Mackall
2007-04-04 2:43 ` [PATCH 10/13] maps: Make /proc/pid/smaps optional under CONFIG_EMBEDDED Matt Mackall
2007-04-04 2:43 ` [PATCH 11/13] maps: Make /proc/pid/clear_refs option " Matt Mackall
2007-04-04 6:22 ` David Rientjes
2007-04-04 2:43 ` [PATCH 12/13] maps: Add /proc/pid/pagemap interface Matt Mackall
2007-04-04 11:18 ` Nikita Danilov
2007-04-04 16:32 ` Matt Mackall
2007-04-04 18:03 ` Nikita Danilov
2007-04-04 21:59 ` Matt Mackall
2007-04-04 2:43 ` [PATCH 13/13] maps: Add /proc/kpagemap interface Matt Mackall
2007-04-12 23:10 ` [PATCH 0/13] maps: pagemap, kpagemap, and related cleanups William Lee Irwin III
2007-04-12 23:32 ` Andrew Morton
2007-04-12 23:42 ` William Lee Irwin III
2007-04-13 0:25 ` Nick Piggin
2007-04-13 0:15 ` Nick Piggin
2007-04-13 0:25 ` Matt Mackall
2007-04-13 1:01 ` Nick Piggin
2007-04-13 1:38 ` Matt Mackall
2007-04-13 2:11 ` Nick Piggin
2007-04-13 0:42 ` Andrew Morton
2007-04-13 1:14 ` Nick Piggin
2007-04-13 1:22 ` Andrew Morton
2007-04-13 1:42 ` Nick Piggin [this message]
2007-04-13 1:57 ` Matt Mackall
2007-04-13 2:21 ` Nick Piggin
2007-04-13 2:23 ` Matt Mackall
2007-04-13 2:54 ` Nick Piggin
2007-04-13 12:24 ` Ananth N Mavinakayanahalli
2007-04-14 8:13 ` Maneesh Soni
2007-04-13 1:57 ` Andrew Morton
2007-04-13 2:05 ` Matt Mackall
2007-04-13 2:29 ` Nick Piggin
2007-04-13 2:18 ` Nick Piggin
2007-04-13 2:32 ` Andrew Morton
2007-04-13 2:50 ` Nick Piggin
2007-04-13 3:10 ` Nick Piggin
2007-04-13 6:53 ` William Lee Irwin III
2007-04-13 7:05 ` Nick Piggin
2007-04-13 7:51 ` Christoph Hellwig
2007-04-13 8:03 ` Nick Piggin
2007-04-13 8:13 ` Christoph Hellwig
2007-04-13 8:25 ` Nick Piggin
2007-04-13 9:46 ` Christoph Hellwig
2007-04-13 21:17 ` Frank Ch. Eigler
2007-04-16 10:59 ` Christoph Hellwig
2007-04-16 21:36 ` Andi Kleen
2007-04-16 21:01 ` Frank Ch. Eigler
2007-04-13 8:15 ` William Lee Irwin III
2007-04-13 12:13 ` Ananth N Mavinakayanahalli
2007-04-13 12:46 ` Nick Piggin
2007-04-13 3:40 ` Nick Piggin
2007-04-13 6:55 ` William Lee Irwin III
2007-04-13 7:03 ` Nick Piggin
2007-04-13 7:08 ` William Lee Irwin III
2007-04-13 14:08 ` Theodore Tso
2007-04-16 11:00 ` Christoph Hellwig
2007-04-13 17:13 ` Matt Mackall
2007-04-13 16:24 ` Matt Mackall
2007-04-13 17:03 ` Andrew Morton
2007-04-13 17:24 ` Matt Mackall
2007-04-13 17:58 ` Andrew Morton
2007-04-13 0: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=461EE005.6070605@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mpm@selenic.com \
--cc=wli@holomorphy.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: 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