"Gianluca Sforna" <giallu@xxxxxxxxx> 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 _______________________________________________ Fedora-kernel-list mailing list Fedora-kernel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-kernel-list
