Re: [PATCH 0/13] maps: pagemap, kpagemap, and related cleanups

[Nick Piggin <nickpiggin@yahoo.com.au>]

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 info. So why can't
> > > > it be used? (not just for kpagemap, but for clear_refs and all that gunk
> > > > too).
> > >
> > >
> > > kprobes is good for looking at events, but bad for looking at state.
> > > Especially metric shitloads of state.
> >
> > Why? Why is a kprobes trap significantly more expensive than a read
> > syscall?
>
>
> I guess I'm not clear on what you're proposing. From my understanding
> of kprobes (admittedly not an expert), this is hard to do and not a
> very good match.

But you have an idea that it is bad for exposing lots of data. Why?
(I'm not a kprobes expert either, these are not rhetorical questions)

From what it looks like, you can traverse data structures and copy data
back to userspace. Which is what makes me think it might be suitable
(or could be made suitable).


> > > > 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.
> > >
> > >
> > > Those are actually probably a good match for systemtap as they're all 
> > > events.
> >
> > Traverse the LRU? Which files do they belong to? What process maps them?
>
>
> -ENOPARSE.

Basically, any "stuff" other than what you're exposing.

--
SUSE Labs, Novell Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/