Date: Wed, 10 Dec 2008 23:15:43 +0100 From: "=?ISO-8859-1?Q?Marius_N=FCnnerich?=" <marius@nuenneri.ch> To: freebsd-geom@freebsd.org Cc: Alexander@leidinger.net, jb@freebsd.org, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: DTrace probes for geom_kern, geom_io and geom_event Message-ID: <b649e5e0812101415x3ca00e03pe2be350141596a72@mail.gmail.com> In-Reply-To: <b649e5e0812041241y143254e0k5e1bae385fc9ae2b@mail.gmail.com> References: <b649e5e0812041241y143254e0k5e1bae385fc9ae2b@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
current CC'ed, maybe there are some people interested in DTrace that don't read geom. On Thu, Dec 4, 2008 at 9:41 PM, Marius N=FCnnerich <marius@nuenneri.ch> wro= te: > Hi, > > I wrote a bunch of DTrace probes for the core geom files mentioned in > the subject. The patch for current is available at > http://nuenneri.ch/freebsd/geom_probes.patch > > Anyone interested in testing them? Just apply the patch, add options > KDTRACE_HOOKS to your kernel and build it like this: > # make WITH_CTF=3D1 KERNCONF=3DYOURKERNEL buildkernel installkernel > > After reboot you can > # kldload dtraceall > and see the new probes with > # dtrace -lP geom > > A sample script: > #!/usr/sbin/dtrace -s > #pragma D option quiet > > geom::: > { > @geom[execname, probemod, probefunc, probename] =3D count(); > @geom_all[execname, probemod, probefunc, probename] =3D count(); > } > > tick-10sec > { > normalize(@geom, 10) > printa("%@8u %@8u %12s %s:%s:%s\n", @geom_all, @geom); > printf("\n"); > clear(@geom); > } > > This is hand copied. You can chmod 755 and run it. > > I'm not sure how to handle the opt_kdtrace.h case in geom.h, see patch li= ne 842. > Any comments on the patch? > > @phk: Are you interested in committing this when there are no > complaints? Are you interested in more probes? After some tips from Alexander Leidinger I updated the patch, new version h= ere: http://nuenneri.ch/freebsd/geom_probes2.patch There are some questions I'd like to discuss: 1. I wrote the SDT_PROBE_DEFINEs right before the function definition, I know this violates the usual style as that stuff would normally belong to the top of the file. I think in this case it would be worthwhile to break with this tradition 2. Should I use the full function name for the probes (with the g_ prefix) even though it's defined under the provider geom 3. Should there be a probe for every switch case in g_io_check? I think this won't work with the fall-through that is used right now 4. Alexander proposed to change the module name kern to core. I'm not sure about this as kern refers to the filename, like io and event do 5. I'm thinking about defining a G_TRACE macro for SDT_PROBE(geom, ...) 6. Does anybody know of a way to probe functions with varargs properly? Like g_trace 7. What about g_bioq_(un)lock functions, I just added one probe for it, I do not really see a point in adding entry and return probes (they are there with FBT anyway). This is consistent with g_topology_lock etc. What about making macros of the two functions like g_topology_lock 8. What about adding macros for (un)locking other locks like g_eventlock, so one could add probes and trace them 9. Writing hundreds of entry and return probes is boring, especially as there is the FBT provider. Maybe it's possible to give the FBT probes better names like geom:io:g_io_schedule_down:entry instead of fbt:kernel:g_io_schedule:entry. Every FBT probe has a provider of fbt und module of kernel right now. One also has to define the argument types which I think FBT figures out by itself. If this would work we could concentrate on adding SDT probes to interesting places inside of functions or macros Bye Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b649e5e0812101415x3ca00e03pe2be350141596a72>