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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 

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 the kernel. If not, then why did we even
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, bloated,
in and odd language, and does a lot of really wrong things in it's runtime).


OK, I pick systemtap because I don't know any better... but kprobes
is what I mean for the kernel interface.



This module allows me to put probes into various places in the scheduler
and writes them into a ringbuffer with timestampts allowing me to
trace what's going on there.  This is really neat.  Unfortunately it
breaks as soon as I do some major reshuffling because then the points
it hooks up to are not there anymore.  That's perfectly fine for my
setup, because _I_ know what I have to change when it breaks, and can
easily fix that.  Now imagine a similar module to trace pagecache activity
used by a third-party monitoring tool.  We now get a major change to
the pagecache (say to make it lockless), and the probes just break.  In
the est case it just doesn't work anymore, in the worst case it crashes
the kernel.  Now if the app vendor at least gave me their source I
could at least fix it to not crash, but there's a fair enough chance
they poke into bits that simply aren't there anymore.

Now if we have a proper user interface with real code behing it we can
have a defined interface.  If the interface is bad enough (or just too
lowlevel) we might have the last problem of stastistic that were there
once to go away aswell, but we can deal with that gracefully by declaring
parts of the stats volatile and make sure people don't mess with them.

To summarize, I really love kprobes to ease my debugging work, but using
it for any kind of production code is a total nightmare.


OK, well Matt's stuff that he needs doesn't have to be kprobes at all,
and yes if lots of people want the same thing then we could distribute
it with the kernel.

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 you what is going on in the VM, it gives you a tiny
window into "something". Between reading a /proc/pid/ pfn and finding
the pfn's page flags, it could be used for something completely different
anyway.



We could distribute some systemtap scripts, and even distribute some
basic useful ones like this sort of page info in the kernel source
tree.



We could not really distribute systemtap scripts with the kernel.
systemtap is a bloody complicated piece of shit outside the kernel
tree that breaks all the time we change kernel internals.  We could
provide useful kprobes modules, a proper tracing system (ltt-ng-lite)
and surrounding infrastucture.


OK ;)

--
SUSE Labs, Novell Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux