Hi, I just finished removing the sysprof-kmod package from CVS as mandated by the new guidelines for F9 and above.
I am now seeking some help to understand what is needed to have again the kernel module required for proper operations of the sysprof package.
Upstream sources are at: http://www.daimi.au.dk/~sandmann/sysprof/
Thanks in advance
Gianluca
On Sun, Dec 02, 2007 at 01:02:23AM +0100, Gianluca Sforna wrote:
Hi, I just finished removing the sysprof-kmod package from CVS as mandated by the new guidelines for F9 and above.
I am now seeking some help to understand what is needed to have again the kernel module required for proper operations of the sysprof package.
Upstream sources are at: http://www.daimi.au.dk/~sandmann/sysprof/
The upstream kernel is likely to eventually get support for perfmon2 integrated, but this could really use more work. It's been in -mm for a while. If there's anything that sysprof can do that perfmon can't (which would be surprising given perfmons featuritis) it would useful to talk with the perfmon developers so we can eventually arrive at an upstreamed solution and not have to worry about integrating out-of-tree patches.
Dave
On Dec 2, 2007 1:09 AM, Dave Jones davej@redhat.com wrote:
On Sun, Dec 02, 2007 at 01:02:23AM +0100, Gianluca Sforna wrote:
Hi, I just finished removing the sysprof-kmod package from CVS as mandated by the new guidelines for F9 and above.
I am now seeking some help to understand what is needed to have again the kernel module required for proper operations of the sysprof package.
Upstream sources are at: http://www.daimi.au.dk/~sandmann/sysprof/
The upstream kernel is likely to eventually get support for perfmon2 integrated, but this could really use more work. It's been in -mm for a while. If there's anything that sysprof can do that perfmon can't (which would be surprising given perfmons featuritis) it would useful to talk with the perfmon developers so we can eventually arrive at an upstreamed solution and not have to worry about integrating out-of-tree patches.
Thanks Dave, this is an interesting information, so I am CCing the upstream author (just in case he is not subscribed to this list).
Now I still wonder what to do here because: 1. it's not sure if this perfmon2 will be in Fedora kernels before F9 ships 2. sysprof has to be adapted to use perfmon2
I mean, it's clear that 1+2 it's the best thing we could come out with, but I'd like to have working sysprof in the repo until that materialize. To this end, please weight in that this is just a single module (one .c and its .h) loaded by the user only when needed. Of course, I can not argue with you about the implications of including this into the kernel package, but I really would like a B plan if we will not have a perfmon enabled kernel+userspace available in time.
On Sat, 2007-12-01 at 19:09 -0500, Dave Jones wrote:
On Sun, Dec 02, 2007 at 01:02:23AM +0100, Gianluca Sforna wrote:
Hi, I just finished removing the sysprof-kmod package from CVS as mandated by the new guidelines for F9 and above.
I am now seeking some help to understand what is needed to have again the kernel module required for proper operations of the sysprof package.
Upstream sources are at: http://www.daimi.au.dk/~sandmann/sysprof/
The upstream kernel is likely to eventually get support for perfmon2 integrated, but this could really use more work. It's been in -mm for a while. If there's anything that sysprof can do that perfmon can't (which would be surprising given perfmons featuritis) it would useful to talk with the perfmon developers so we can eventually arrive at an upstreamed solution and not have to worry about integrating out-of-tree patches.
Until that happens can we please carry the patch in the Fedora kernel? IIRC it's not invasive at all. And it's really annoying not being able to use sysprof. Thanks.
David
On Sun, Dec 02, 2007 at 02:04:01AM -0500, David Zeuthen wrote:
Upstream sources are at: http://www.daimi.au.dk/~sandmann/sysprof/
The upstream kernel is likely to eventually get support for perfmon2 integrated, but this could really use more work. It's been in -mm for a while. If there's anything that sysprof can do that perfmon can't (which would be surprising given perfmons featuritis) it would useful to talk with the perfmon developers so we can eventually arrive at an upstreamed solution and not have to worry about integrating out-of-tree patches.
Until that happens can we please carry the patch in the Fedora kernel? IIRC it's not invasive at all. And it's really annoying not being able to use sysprof. Thanks.
The problem is I really hate adding patches that provide new user interfaces. It's easy enough to add it, but it'll be a 'fedora-ism' that doesn't work in any other distro, or with an upstream kernel. And what happens if someone starts building more things on top of the sysprof exports?
It's the same reason patches that add syscalls get vetoed. We don't want to be in a situation where it appears we're locking users into running our distro/kernel.
Dave
On Sun, 2007-12-02 at 02:10 -0500, Dave Jones wrote:
On Sun, Dec 02, 2007 at 02:04:01AM -0500, David Zeuthen wrote: The problem is I really hate adding patches that provide new user interfaces. It's easy enough to add it, but it'll be a 'fedora-ism' that doesn't work in any other distro, or with an upstream kernel. And what happens if someone starts building more things on top of the sysprof exports?
It's the same reason patches that add syscalls get vetoed. We don't want to be in a situation where it appears we're locking users into running our distro/kernel.
What if the sysprof author offered
a. to maintain the patch in the SRPM (e.g. make sure it works) b. to work with upstream to either get it his patch in or migrate to another interface when available
Would that work? Dave? Søren?
David
On Dec 2, 2007 10:33 PM, David Zeuthen davidz@redhat.com wrote:
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
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...
"Gianluca Sforna" giallu@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
On Tue, Dec 04, 2007 at 03:57:43PM -0500, Soeren Sandmann Pedersen wrote:
As for perfmon2, I haven't looked at it in a long time, but assuming it's a superset of the oprofile interface
bad assumption. The two are completely separate things. In theory oprofile could be rewritten to be a 'personality' of perfmon2. It's a lot more capable. (One complaint against its inclusion right now is that it's _too_ feature rich)
Dave
Dave Jones davej@redhat.com writes:
On Tue, Dec 04, 2007 at 03:57:43PM -0500, Soeren Sandmann Pedersen wrote:
As for perfmon2, I haven't looked at it in a long time, but assuming it's a superset of the oprofile interface
bad assumption. The two are completely separate things. In theory oprofile could be rewritten to be a 'personality' of perfmon2.
So that would make perfmon2 features a superset of oprofile features. In that case, if it has the features I listed as missing from oprofile, sysprof could use it.
Soren
On Dec 2, 2007 8:10 AM, Dave Jones davej@redhat.com wrote:
The problem is I really hate adding patches that provide new user interfaces.
I understand this concern
It's easy enough to add it, but it'll be a 'fedora-ism' that doesn't work in any other distro, or with an upstream kernel.
I can't grok this sentence. what do stop working upstream if we add this?
And what happens if someone starts building more things on top of the sysprof exports?
Who should be this "someone"? Anyway, the answer looks like: he get bite when we will drop the patch. How bad is it?
It's the same reason patches that add syscalls get vetoed. We don't want to be in a situation where it appears we're locking users into running our distro/kernel.
Of all the complaints I have seen in the past about our kernels, this never shown up, but I'm sure you collected much more than me...
Point is, you are the kernel maintainer here so, though I can't fully understand your concerns, I assume they are valid and I better stop arguing on things I can not fully evaluate.
So my last question for you is: how are those scenarios likely? I mean, do you see a concrete risk someone will build something on top of the current sysprof interface? It would be really a pity (and a regression) if sysprof will lack the binary module because of some recondite reason.
kernel@lists.fedoraproject.org
-
Dave Jones -
David Zeuthen -
Gianluca Sforna -
Soren Pedersen