Hi -
On Mon, Apr 16, 2007 at 11:36:05PM +0200, Andi Kleen wrote:
> Christoph Hellwig <[EMAIL PROTECTED]> writes:
> > and [systemtap] does a lot of really wrong things in it's
> > runtime). [...]
(Thanks, Christoph, for at least a few specifics. Some of them have
already been dealt with in the re
Christoph Hellwig <[EMAIL PROTECTED]> writes:
> and does a lot of really wrong things in it's runtime).
I must agree with that. Perhaps it would be good if its runtime code
was posted to l-k at some point and reviewed in the standard way
even when it isn't merged.
-Andi
-
To unsubscribe from thi
On Fri, Apr 13, 2007 at 10:08:27AM -0400, Theodore Tso wrote:
> On Fri, Apr 13, 2007 at 01:40:08PM +1000, Nick Piggin wrote:
> > With systemtap scripts, you could walk pagetables and print *the exact
> > page information you want*, or you could walk pfns, or LRU, or page_tree,
> > or walk the page
On Fri, Apr 13, 2007 at 05:17:00PM -0400, Frank Ch. Eigler wrote:
> It may be worthwhile to remind people that it is easy to use systemtap
> only to the extent of automating the placement of kprobes: just to
> perform the function-name/source-file/line-number triplet to PC
> mapping. They can use
On Thu, Apr 12, 2007 at 09:23:45PM -0500, Matt Mackall wrote:
> On Fri, Apr 13, 2007 at 12:21:25PM +1000, Nick Piggin wrote:
> > Matt Mackall wrote:
> > >On Fri, Apr 13, 2007 at 11:42:29AM +1000, Nick Piggin wrote:
> >
> > >>If kprobes is simply crappy and doesn't work properly for this, then I
>
Christoph Hellwig <[EMAIL PROTECTED]> writes:
> [...]
> > merge it in the first place?
>
> It's very nice to poke deep into the kernel for development purposes.
> For example for the spu scheduler work I'm doing currently I have
> a module using kprobes (note the systemtap crap because it's big,
On Fri, 13 Apr 2007 12:24:51 -0500 Matt Mackall <[EMAIL PROTECTED]> wrote:
> > > From /proc/kpagemap + /proc/*/pagemap, you can
> > > basically synthesize any statistic you want, including all the
> > > existing ones. For some data, /proc/pid/smaps (or /proc/meminfo) will
> > > be considerably mor
On Fri, Apr 13, 2007 at 10:03:56AM -0700, Andrew Morton wrote:
> On Fri, 13 Apr 2007 11:24:36 -0500 Matt Mackall <[EMAIL PROTECTED]> 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
On Fri, Apr 13, 2007 at 12:18:56PM +1000, Nick Piggin wrote:
> Can't you just traverse arbitrary kernel data structures at a given point
> in time, exactly like the /proc/ call is doing?
Perhaps.
My understanding is that you hook a kprobe to an event. An event is a
particular instruction getting
On Fri, 13 Apr 2007 11:24:36 -0500 Matt Mackall <[EMAIL PROTECTED]> 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 c
On Thu, Apr 12, 2007 at 05:42:01PM -0700, Andrew Morton wrote:
> On Fri, 13 Apr 2007 10:15:24 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > >>+ ((char *)page)[1] = PAGE_SHIFT;
> > >
> > >
> > > OK.
> >
> > Shouldn't we just expose page size and endianness by other mea
On Fri, Apr 13, 2007 at 01:40:08PM +1000, Nick Piggin wrote:
> With systemtap scripts, you could walk pagetables and print *the exact
> page information you want*, or you could walk pfns, or LRU, or page_tree,
> or walk the page tree then the rmap structures. And you can selectively
> cull out item
Ananth N Mavinakayanahalli wrote:
On Fri, Apr 13, 2007 at 12:50:20PM +1000, Nick Piggin wrote:
It definitely seems like you can use some kernel functions, but the
ones I saw may just be systemtap facilities. But what is so surprising
about being able to call a kernel function when running in k
On Fri, Apr 13, 2007 at 12:54:36PM +1000, Nick Piggin wrote:
> Matt Mackall wrote:
> >On Fri, Apr 13, 2007 at 12:21:25PM +1000, Nick Piggin wrote:
> >
> >>Matt Mackall wrote:
> >>
> >>>On Fri, Apr 13, 2007 at 11:42:29AM +1000, Nick Piggin wrote:
> >>
> If kprobes is simply crappy and doesn't wo
On Fri, Apr 13, 2007 at 12:50:20PM +1000, Nick Piggin wrote:
> Andrew Morton wrote:
> >On Fri, 13 Apr 2007 12:18:56 +1000 Nick Piggin <[EMAIL PROTECTED]>
> >wrote:
> >
> >
> >>>I guess one could generate an answer to the static question with
> >>>systemtap,
> >>>by accumulating running counts acr
On Fri, Apr 13, 2007 at 06:25:46PM +1000, Nick Piggin wrote:
> But at least make it into its own module with a debugfs interface or
> something. I mean, exposing a PG_name-to-nr and page count pfn and flags
> as a supposedly formal proc interface doesn't sound nice to me. Page
> flags does not tell
Christoph Hellwig wrote:
On Fri, Apr 13, 2007 at 06:03:45PM +1000, Nick Piggin wrote:
Yeah good point ;) I just meant the wider "we".
With all the problems kprobes has, something like poking deep into
kernel internals seems like a good thing to use it for instead of
hardcoding that stuff into
On Fri, Apr 13, 2007 at 08:51:42AM +0100, Christoph Hellwig wrote:
> Umm, folks. systemtap basically means people compile kernel modules
> from an odd scripting language with embedded C snipplets into kernel
> modules. The kernel modules don't use normal exported APIs but use
> kallsysms and dwar
On Fri, Apr 13, 2007 at 06:03:45PM +1000, Nick Piggin wrote:
> Yeah good point ;) I just meant the wider "we".
>
> With all the problems kprobes has, something like poking deep into
> kernel internals seems like a good thing to use it for instead of
> hardcoding that stuff into the kernel. If not,
Christoph Hellwig wrote:
On Fri, Apr 13, 2007 at 05:05:47PM +1000, Nick Piggin wrote:
Ah, OK. Anyway, with kprobes/systemtap they can do whatever they like
and none of us need to care in the slightest ;)
Umm, folks. systemtap basically means people compile kernel modules
from an odd scripti
On Fri, Apr 13, 2007 at 05:05:47PM +1000, Nick Piggin wrote:
> Ah, OK. Anyway, with kprobes/systemtap they can do whatever they like
> and none of us need to care in the slightest ;)
Umm, folks. systemtap basically means people compile kernel modules
from an odd scripting language with embedded C
William Lee Irwin III wrote:
>> The EM guys are unwilling or unable for support-oriented reasons to
>> deal with anything but unmodified kernels as shipped by distros.
On Fri, Apr 13, 2007 at 05:03:43PM +1000, Nick Piggin wrote:
> And I think major distros ship with kprobes enabled, so that is yet
William Lee Irwin III wrote:
Andrew Morton wrote:
Then you just end up with the same thing, don't you?
On Fri, Apr 13, 2007 at 12:50:20PM +1000, Nick Piggin wrote:
Well _you_ do, because that happens to be exactly what you want. Bill
ends up with something that displays page_mapcount inste
William Lee Irwin III wrote:
Andrew Morton wrote:
Do a full pagetable walk, with all the associated locking from within
a systemtap script? I'd be surprised. Maybe if it's mostly hand-coded
in C, perhaps. Then you just end up with the same thing, don't you?
On Fri, Apr 13, 2007 at 01:40:0
Andrew Morton wrote:
>> Do a full pagetable walk, with all the associated locking from within
>> a systemtap script? I'd be surprised. Maybe if it's mostly hand-coded
>> in C, perhaps. Then you just end up with the same thing, don't you?
On Fri, Apr 13, 2007 at 01:40:08PM +1000, Nick Piggin wro
Andrew Morton wrote:
>> Then you just end up with the same thing, don't you?
On Fri, Apr 13, 2007 at 12:50:20PM +1000, Nick Piggin wrote:
> Well _you_ do, because that happens to be exactly what you want. Bill
> ends up with something that displays page_mapcount instead. And I
> end up with someth
Andrew Morton wrote:
On Fri, 13 Apr 2007 12:18:56 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
I guess one could generate an answer to the static question with systemtap,
by accumulating running counts across the application lifetime and then
snapshotting them. Sounds hard though.
Can't you
Nick Piggin wrote:
Andrew Morton wrote:
Then you just end up with the same thing, don't you?
Well _you_ do, because that happens to be exactly what you want. Bill
ends up with something that displays page_mapcount instead. And I
end up with something that traverses LRU lists rather than pf
Matt Mackall wrote:
On Fri, Apr 13, 2007 at 12:21:25PM +1000, Nick Piggin wrote:
Matt Mackall wrote:
On Fri, Apr 13, 2007 at 11:42:29AM +1000, Nick Piggin wrote:
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 inf
Andrew Morton wrote:
On Fri, 13 Apr 2007 12:18:56 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
I guess one could generate an answer to the static question with systemtap,
by accumulating running counts across the application lifetime and then
snapshotting them. Sounds hard though.
Can't you
On Fri, Apr 13, 2007 at 12:21:25PM +1000, Nick Piggin wrote:
> Matt Mackall wrote:
> >On Fri, Apr 13, 2007 at 11:42:29AM +1000, Nick Piggin wrote:
>
> >>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
On Fri, 13 Apr 2007 12:18:56 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
> > I guess one could generate an answer to the static question with systemtap,
> > by accumulating running counts across the application lifetime and then
> > snapshotting them. Sounds hard though.
>
> Can't you just trav
Matt Mackall wrote:
On Thu, Apr 12, 2007 at 06:57:23PM -0700, Andrew Morton wrote:
I guess one could generate an answer to the static question with systemtap,
by accumulating running counts across the application lifetime and then
snapshotting them. Sounds hard though.
You'd have to do it f
Matt Mackall wrote:
On Fri, Apr 13, 2007 at 11:42:29AM +1000, Nick Piggin wrote:
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 g
Andrew Morton wrote:
On Fri, 13 Apr 2007 11:42:29 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
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 l
On Thu, Apr 12, 2007 at 06:57:23PM -0700, Andrew Morton wrote:
> I guess one could generate an answer to the static question with systemtap,
> by accumulating running counts across the application lifetime and then
> snapshotting them. Sounds hard though.
You'd have to do it from boot onward to g
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 kn
On Fri, Apr 13, 2007 at 11:42:29AM +1000, Nick Piggin wrote:
> >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...
It'd be really
On Fri, 13 Apr 2007 11:42:29 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > On Fri, 13 Apr 2007 11:14:20 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
> >
> >
> >>Andrew Morton wrote:
>
> >>>It *will* be viable. If the application wants to know if a page is dirty,
> >>>
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 singl
Andrew Morton wrote:
On Fri, 13 Apr 2007 11:14:20 +1000 Nick Piggin <[EMAIL PROTECTED]> 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 inspec
On Fri, 13 Apr 2007 11:14:20 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > On Fri, 13 Apr 2007 10:15:24 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> + for (; i < 2 * chunk / KPMSIZE; i += 2, pfn++) {
> + ppage = pfn_to_page
Andrew Morton wrote:
On Fri, 13 Apr 2007 10:15:24 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
+ for (; i < 2 * chunk / KPMSIZE; i += 2, pfn++) {
+ ppage = pfn_to_page(pfn);
+ if (!ppage) {
+ page[i] = 0;
+
Matt Mackall wrote:
On Fri, Apr 13, 2007 at 10:15:24AM +1000, Nick Piggin wrote:
Andrew Morton wrote:
On Thu, 12 Apr 2007 16:10:50 -0700
William Lee Irwin III <[EMAIL PROTECTED]> wrote:
+ while (count > 0) {
+ chunk = min_t(size_t, count, PAGE_SIZE);
+ i =
On Fri, 13 Apr 2007 10:15:24 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
> >>+ ((char *)page)[1] = PAGE_SHIFT;
> >
> >
> > OK.
>
> Shouldn't we just expose page size and endianness by other means? (another
> file or
> syscall).
I don't think so - this file exposes fairl
On Fri, Apr 13, 2007 at 10:15:24AM +1000, Nick Piggin wrote:
> Andrew Morton wrote:
> >On Thu, 12 Apr 2007 16:10:50 -0700
> >William Lee Irwin III <[EMAIL PROTECTED]> wrote:
>
> >>+ while (count > 0) {
> >>+ chunk = min_t(size_t, count, PAGE_SIZE);
> >>+ i = 0;
>
On Thu, Apr 12, 2007 at 04:32:35PM -0700, Andrew Morton wrote:
> On Thu, 12 Apr 2007 16:10:50 -0700
> William Lee Irwin III <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Apr 03, 2007 at 09:43:30PM -0500, Matt Mackall wrote:
> > > This patch series introduces /proc/pid/pagemap and /proc/kpagemap,
> > >
William Lee Irwin III wrote:
On Thu, 12 Apr 2007 16:10:50 -0700 William Lee Irwin III <[EMAIL PROTECTED]>
wrote:
This solves a real-life problem for Oracle system monitoring software
(specifically EM). Among the tasks it must carry out is determining
per-process memory footprint of a set of co
Andrew Morton wrote:
On Thu, 12 Apr 2007 16:10:50 -0700
William Lee Irwin III <[EMAIL PROTECTED]> wrote:
+ while (count > 0) {
+ chunk = min_t(size_t, count, PAGE_SIZE);
+ i = 0;
+
+ if (pfn == -1) {
+ page[0] = 0;
+
On Thu, 12 Apr 2007 16:10:50 -0700 William Lee Irwin III <[EMAIL PROTECTED]>
wrote:
>> This solves a real-life problem for Oracle system monitoring software
>> (specifically EM). Among the tasks it must carry out is determining
>> per-process memory footprint of a set of cooperating tasks (i.e. Or
On Thu, 12 Apr 2007 16:10:50 -0700
William Lee Irwin III <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 03, 2007 at 09:43:30PM -0500, Matt Mackall wrote:
> > This patch series introduces /proc/pid/pagemap and /proc/kpagemap,
> > which allow detailed run-time examination of process memory usage at a
> >
On Tue, Apr 03, 2007 at 09:43:30PM -0500, Matt Mackall wrote:
> This patch series introduces /proc/pid/pagemap and /proc/kpagemap,
> which allow detailed run-time examination of process memory usage at a
> page granularity.
> The first several patches whip the page-walking code introduced for
> /pr
This patch series introduces /proc/pid/pagemap and /proc/kpagemap,
which allow detailed run-time examination of process memory usage at a
page granularity.
The first several patches whip the page-walking code introduced for
/proc/pid/smaps and clear_refs into a more generic form, the next
couple m
53 matches
Mail list logo
