[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <461EE6E9.3070104@yahoo.com.au>
Date: Fri, 13 Apr 2007 12:11:53 +1000
From: Nick Piggin <nickpiggin@...oo.com.au>
To: Matt Mackall <mpm@...enic.com>
CC: Andrew Morton <akpm@...ux-foundation.org>,
William Lee Irwin III <wli@...omorphy.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/13] maps: pagemap, kpagemap, and related cleanups
Matt Mackall wrote:
> On Fri, Apr 13, 2007 at 11:01:41AM +1000, Nick Piggin wrote:
>
>>>Basically: to show what the hell's going on in the VM.
>>
>>kprobes / systemtap isn't good enough?
>
>
> It's not really a good match to the kprobes model. I'm not interested
> in events, per se. I don't want to need to know about every single
> alloc/free of N different varieties integrated from boot onward to
> build up an image of the state of the system. Instead, I want to take
> snapshots of the state of the VM.
Systemtap can't output a large set of values?
Why can't you attach a kprobe to a dummy syscall, and from there
iterate over pgdat/zone/memmap and output what you want?
Actually I'm surprised that kind of data querying facility isn't
already in there (I haven't used it seriously though).
> The main goal here is to be able to answer the question "where's my
> memory going?". Currently you can't really give a good answer to that
> question from userspace because of shared mappings, etc.
>
> There are lots of secondary questions that follow on very quickly from
> that, like "what parts of my shared mappings are or aren't shared, and
> why?", "what's actually in my application's working set?" and "how much
> of this crap can I ditch?".
I understand roughly what you want, and that you can't easily get
it from /proc currently. My question at this point is just why can
we not use systemtap.
--
SUSE Labs, Novell Inc.
-
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