[opensuse-kernel] Trace flavor still needed?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all - Bnc#656091 asks about enabling UTRACE for other kernel flavors. It's too late to do it for 11.4 since enabling it modifies struct task_struct. However, most of the trace infrastructure appears to use jump labels now, which means that they're essentially free when not in use. I'd like to eliminate the trace flavor for the 12.1 release. At this point the only differences are ftrace and utrace. Has anyone done the legwork to verify the performance impact here? I suppose since it's only in Factory for now we can just change it and see what shakes out. Opinions? - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk2t5QYACgkQLPWxlyuTD7LCEgCbBKbn7GcGfG2wtPSKzdyWd1X1 DOIAnijd/HP8jDvRxsgfgJvNoj34Q52t =feDe -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
Jeff Mahoney píše v Út 19. 04. 2011 v 15:39 -0400:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi all -
Bnc#656091 asks about enabling UTRACE for other kernel flavors. It's too late to do it for 11.4 since enabling it modifies struct task_struct. However, most of the trace infrastructure appears to use jump labels now, which means that they're essentially free when not in use.
I'd like to eliminate the trace flavor for the 12.1 release. At this point the only differences are ftrace and utrace.
Has anyone done the legwork to verify the performance impact here? I suppose since it's only in Factory for now we can just change it and see what shakes out.
Hi Jeff, I'll only talk about the utrace part. First, bug 656091 says that CONFIG_UTRACE is needed for systemtap to work. This is not true. Or rather, it's true only if you specifically enable utrace support in systemtap. Second, UTRACE has never been and will never be accepted in mainline, AFAICS. OTOH, since it's a Redhat-specific out-of-tree patch, it might be requested by PM anyway to achieve "RHEL parity". Third, the utrace project seems to be dead (or at least on hold since December where all traffic stopped on the utrace-devel mailing list). This raises lots of concern about the future of the UTRACE patch. Fourth, what do you mean by "it's only in Factory"? CONFIG_UTRACE is certainly not enabled for vanilla or default, is it?
Opinions?
At this point, if you want to reduce the number of flavours, I vote for dropping the UTRACE patch. It's bad enough I'll have to maintain it for the SLE11 branch. Petr Tesarik L3 International
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/20/2011 03:36 AM, Petr Tesarik wrote:
Jeff Mahoney píše v Út 19. 04. 2011 v 15:39 -0400:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi all -
Bnc#656091 asks about enabling UTRACE for other kernel flavors. It's too late to do it for 11.4 since enabling it modifies struct task_struct. However, most of the trace infrastructure appears to use jump labels now, which means that they're essentially free when not in use.
I'd like to eliminate the trace flavor for the 12.1 release. At this point the only differences are ftrace and utrace.
Has anyone done the legwork to verify the performance impact here? I suppose since it's only in Factory for now we can just change it and see what shakes out.
Hi Jeff,
I'll only talk about the utrace part.
First, bug 656091 says that CONFIG_UTRACE is needed for systemtap to work. This is not true. Or rather, it's true only if you specifically enable utrace support in systemtap.
Second, UTRACE has never been and will never be accepted in mainline, AFAICS. OTOH, since it's a Redhat-specific out-of-tree patch, it might be requested by PM anyway to achieve "RHEL parity".
Third, the utrace project seems to be dead (or at least on hold since December where all traffic stopped on the utrace-devel mailing list). This raises lots of concern about the future of the UTRACE patch.
Well if that's the case, then perhaps we should just drop it completely. Another goal I have for openSUSE is to strip out as many of the patches we're carrying as possible.
Fourth, what do you mean by "it's only in Factory"? CONFIG_UTRACE is certainly not enabled for vanilla or default, is it?
I mean if we enable it now and see what shakes out, it won't affect an actual release until November. If there's no utrace support then it's even easier to drop the trace flavor. - -Jeff
Opinions?
At this point, if you want to reduce the number of flavours, I vote for dropping the UTRACE patch. It's bad enough I'll have to maintain it for the SLE11 branch.
Petr Tesarik L3 International
- -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk2u8sEACgkQLPWxlyuTD7KppQCfU+CvGnI+kfefb11j7tWR+Pp0 r6YAn2U5978cuyrYuMjE2UC4g8iqBTXL =i/6I -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Wed, Apr 20, 2011 at 09:36:18AM +0200, Petr Tesarik wrote:
Hi Jeff,
I'll only talk about the utrace part.
First, bug 656091 says that CONFIG_UTRACE is needed for systemtap to work. This is not true. Or rather, it's true only if you specifically enable utrace support in systemtap.
Second, UTRACE has never been and will never be accepted in mainline, AFAICS. OTOH, since it's a Redhat-specific out-of-tree patch, it might be requested by PM anyway to achieve "RHEL parity".
Third, the utrace project seems to be dead (or at least on hold since December where all traffic stopped on the utrace-devel mailing list). This raises lots of concern about the future of the UTRACE patch.
Fourth, what do you mean by "it's only in Factory"? CONFIG_UTRACE is certainly not enabled for vanilla or default, is it?
Hi No, just for -trace as per your commit 659cb3e9cff. It looks like I refreshed it for OpenSUSE, probably when I fixed it for SP1 (see last comment in fate). Only the base patch is included, not the reimplement ptrace using utrace patch. So there isn't a performance cost to having it. I agree, it's a total dead-end mainline wise but it is necessary to support the stap feature. Also, there is no specific enabling of uprobes in stap, rather I'd have to look into a way of specifically disabling it an earlier/cleaner error is desired. Tony -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
participants (3)
-
Jeff Mahoney -
Petr Tesarik -
Tony Jones