Getting rid of sysprof-kmod

Soeren Sandmann Pedersen sandmann at redhat.com
Tue Dec 4 20:57:43 UTC 2007


"Gianluca Sforna" <giallu at gmail.com> writes:

> > What if the sysprof author offered
> >
> >  a. to maintain the patch in the SRPM (e.g. make sure it works)
> 
> This looks like an easy target; I can witness the module sources
> always worked since the package entered in the repo (around FC5 IIRC).
> The few occasional glitches were promptly fixed

I'd certainly be happy to do this, or help out as necessary.

> >  b. to work with upstream to either get it his patch in or migrate
> >     to another interface when available
> 
> Well, last time I asked, the former was not going to happen and I fear
> the latter will be too late for F9...

I am not opposed to getting sysprof into the upstream kernel on some
general principle; I'm just not sure I am ready to set the interface
in stone. And I'm not sure if they'd take it.

As for perfmon2, I haven't looked at it in a long time, but assuming
it's a superset of the oprofile interface, here are the main things
that sysprof does that oprofile doesn't (or didn't last time I looked
at it):

- poll()
- non-blocking read()
- partial reads

- Lost samples (ie. samples where the instruction pointer is not
  inside the text segment of a library) should be reported. Otherwise
  things like JIT compilers or old X servers will not be profiled
  correctly.

- Idle events should not be sent to the client since they just use
  bandwidth.

- The ability to take kernel stacktraces even when the kernel was
  compiled with -fomit-framepointer. Ie., do a conservative
  backtrace.

- The ability to take stacktraces of userspace, even when the
  interrupt happened in kernel mode. Ie,. trace both the kernel and
  the user stack.

- The ability to mmap() the sample buffer to avoid copying the
  information more than once.

Finally, one other thing that oprofile doesn't have, is a simple
API. I did actually at one point write code to make sysprof use the
oprofile module, but the result was not very nice:

It involved mounting a special file system and then opening a bunch of
files, then writing configuration information to those files. All
those calls could potentially fail, requiring graphical applications
to pop up dialogs with gobbledigook messages.

Parsing the output then required an elaborate statemachine that was
further complicated by the need to deal with partial reads.

All this required more than a thousand lines of code, compared to
about 50 for the sysprof interface. But, this is mostly whining; I can
deal with a complicated interface if I have to.


Soren




More information about the Fedora-kernel-list mailing list