-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi all -
I know someone else mentioned this briefly WRT to Tumbleweed, but I'd like to bring up for discussion the adoption of gcc 4.6 for Factory.
A bit of background. We currently maintain a kernel-trace flavor to allow people to make use of the tracing facilities. Historically, there has been overhead associated with these, which is why they were in their own flavor. Most users don't care about them, so there's no sense in slowing everyone down to satisfy them. Over time, the maintainers of these facilities have worked to lower the overhead to the point where now dynamic ftrace only adds memory overhead. It uses gcc's profiling facility to call out to a function at the beginning of every function call to allow tracking. At boot, this is a function that returns immediately but during the boot process those calls are hot-patched to nop operations so that they carry virtually zero runtime overhead.
This sounds great, right? There's one last bit, and that is actually the reason why ftrace is still disabled in our regular kernel flavors. The compiler's profiling feature calls the profiling function after the function prologue. That means that the stack pointer has already been advanced and since it can advance a different amount based on the needs of each function, we don't have an easy way to get the caller's stack frame back. It's needed to resolve where the caller was called from and the only way to do that is to dedicate a register to track the start of the current stack frame. Dedicating a register for this increases register contention and forces more accesses to CPU cache or main memory, slowing everything down. So, it's not worth it when most users will never actually take advantage of the feature that requires it.
For some time, I've been trying to come up with ways to work around this so that the fast path stays fast and the tracing path takes any performance hit necessary. Until recently, the performance hit would've been too big to make it worthwhile. With gcc 4.6, we have the -mfentry option which moves the call to the profiling function *before* the function's prologue. This means that the caller's stack frame is still intact and we can resolve the caller's parent without issue. I've spent the past few days working up a proof of concept that takes advantage of this and doesn't require a dedicated register. It turns out that Steven Rostedt has already posted a patch set to do exactly this and he's targeting 2.6.40 for inclusion in the mainline kernel. For now it looks like it's x86-64 only but it should be ok for i386 as well.
This would go a long way to eliminate the -trace flavor from our kernel packages. The benefits are multiple: It eliminates the maintenance of another kernel flavor, but it also allows everyone to use tracing facilities without installing a separate kernel release to do so.
One last bit is needed, though, and that is for gcc to allow using -pg - -mfentry with -fomit-frame-pointers. Once that bit is taken care of then we can rid the kernel of the frame pointer requirement for ftrace and eliminate the -trace flavor entirely.
- -Jeff
- -- Jeff Mahoney SUSE Labs
On Fri, Apr 29, 2011 at 11:45 AM, Jeff Mahoney jeffm@suse.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi all -
I know someone else mentioned this briefly WRT to Tumbleweed, but I'd like to bring up for discussion the adoption of gcc 4.6 for Factory.
<snipped a lot of good stuff about why a kernel compile with gcc 4.6 is a good thing>
Jeff,
I don't have factory running anywhere, but I thought gcc 4.6 was in factory now, but not as default.
You have to invoke it as gcc46 was my understanding.
Would updating the specfile to use gcc46 instead of gcc be feasible until the default gcc is updated?
Greg
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/29/2011 02:41 PM, Greg Freemyer wrote:
On Fri, Apr 29, 2011 at 11:45 AM, Jeff Mahoney jeffm@suse.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi all -
I know someone else mentioned this briefly WRT to Tumbleweed, but I'd like to bring up for discussion the adoption of gcc 4.6 for Factory.
<snipped a lot of good stuff about why a kernel compile with gcc 4.6 is a good thing>
Jeff,
I don't have factory running anywhere, but I thought gcc 4.6 was in factory now, but not as default.
You have to invoke it as gcc46 was my understanding.
Would updating the specfile to use gcc46 instead of gcc be feasible until the default gcc is updated?
Yeah, that'd be pretty easy. The hard part comes in when you want to build KMPs against that kernel since they won't be using the same compiler version unless they're *also* modified to use CC=gcc-4.6
- -Jeff
- -- Jeff Mahoney SUSE Labs
On 04/29/2011 09:01 PM, Jeff Mahoney wrote:
On 04/29/2011 02:41 PM, Greg Freemyer wrote:
On Fri, Apr 29, 2011 at 11:45 AM, Jeff Mahoney jeffm@suse.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi all -
I know someone else mentioned this briefly WRT to Tumbleweed, but I'd like to bring up for discussion the adoption of gcc 4.6 for Factory.
<snipped a lot of good stuff about why a kernel compile with gcc 4.6 is a good thing>
Jeff,
I don't have factory running anywhere, but I thought gcc 4.6 was in factory now, but not as default.
You have to invoke it as gcc46 was my understanding.
Would updating the specfile to use gcc46 instead of gcc be feasible until the default gcc is updated?
Yeah, that'd be pretty easy. The hard part comes in when you want to build KMPs against that kernel since they won't be using the same compiler version unless they're *also* modified to use CC=gcc-4.6
-Jeff
I guess this begs the question is what needs to be done to enable 4.6 as the default in Factory ?
I know there was a list a while back of packages which were not building on gcc4.6, but have they been resolved ?
The other question I would ask is what other gcc4.6 options might we want to enable by default ? Now it seems would be a good time to contemplate this and do some experiments.
Getting a newer compiler in Factory early would be great for ensuring it gets lots of extended testing. I've branched gcc4.6 from Factory and enabled 11.4 and 11.3 repos for those who might like to experiment. I've tested some packages locally and do not see any real issues.
Comments ?
Cheers,
Peter
Am Freitag, 29. April 2011 schrieb Peter Linnell:
I guess this begs the question is what needs to be done to enable 4.6 as the default in Factory ?
I know there was a list a while back of packages which were not building on gcc4.6, but have they been resolved ?
openSUSE:Factory:Staging:Gcc46 has 116 fails: http://is.gd/S2iwsB
I see less than one package a day fixed, so at that pace we can have gcc 4.6 for 12.2. Of course everyone can fix those packages, but about noone does ;(
Greetings, Stephan
On 29.4.2011 21:01, Jeff Mahoney wrote:
On 04/29/2011 02:41 PM, Greg Freemyer wrote:
Would updating the specfile to use gcc46 instead of gcc be feasible until the default gcc is updated?
Yeah, that'd be pretty easy. The hard part comes in when you want to build KMPs against that kernel since they won't be using the same compiler version unless they're *also* modified to use CC=gcc-4.6
We could save the CC variable in the generated Makefile in the build directory. I'm not sure if it would break in some scenarios, but it should work as a temporary opensuse-only patch at least.
Michal
On 04/29/2011 11:41 PM, Michal Marek wrote:
On 29.4.2011 21:01, Jeff Mahoney wrote:
On 04/29/2011 02:41 PM, Greg Freemyer wrote:
Would updating the specfile to use gcc46 instead of gcc be feasible until the default gcc is updated?
Yeah, that'd be pretty easy. The hard part comes in when you want to build KMPs against that kernel since they won't be using the same compiler version unless they're *also* modified to use CC=gcc-4.6
The question is whether it will break anything in that case at all? Like nvidia and similar binary blob (some v4l drivers for example) won't be built by 4.6 for sure but are expected to work... The tracing won't work, indeed. But will it crash?
We could save the CC variable in the generated Makefile in the build directory. I'm not sure if it would break in some scenarios, but it should work as a temporary opensuse-only patch at least.
Hopefully everybody uses kbuild properly nowadays. But again, is it needed?
thanks,
here it is the list with packages that still fail to build with 4.6 from factory. https://build.opensuse.org/project/monitor?project=openSUSE%3AFactory%3AStag...
Alin
On 30 April 2011 08:25, Jiri Slaby jslaby@suse.cz wrote:
On 04/29/2011 11:41 PM, Michal Marek wrote:
On 29.4.2011 21:01, Jeff Mahoney wrote:
On 04/29/2011 02:41 PM, Greg Freemyer wrote:
Would updating the specfile to use gcc46 instead of gcc be feasible until the default gcc is updated?
Yeah, that'd be pretty easy. The hard part comes in when you want to build KMPs against that kernel since they won't be using the same compiler version unless they're *also* modified to use CC=gcc-4.6
The question is whether it will break anything in that case at all? Like nvidia and similar binary blob (some v4l drivers for example) won't be built by 4.6 for sure but are expected to work... The tracing won't work, indeed. But will it crash?
We could save the CC variable in the generated Makefile in the build directory. I'm not sure if it would break in some scenarios, but it should work as a temporary opensuse-only patch at least.
Hopefully everybody uses kbuild properly nowadays. But again, is it needed?
thanks,
js suse labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 04/30/2011 09:32 AM, Alin Marin Elena wrote:
here it is the list with packages that still fail to build with 4.6 from factory. https://build.opensuse.org/project/monitor?project=openSUSE%3AFactory%3AStag...
Thank people who did that. Many of them are -Werror + -Wunused-but-set problem. That should be easy to fix (but obviously needs man-hours).
thanks,
On 30 April 2011 10:29, Jiri Slaby jslaby@suse.cz wrote:
On 04/30/2011 09:32 AM, Alin Marin Elena wrote:
here it is the list with packages that still fail to build with 4.6 from factory. https://build.opensuse.org/project/monitor?project=openSUSE%3AFactory%3AStag...
Thank people who did that. Many of them are -Werror + -Wunused-but-set problem. That should be easy to fix (but obviously needs man-hours).
thanks,
js suse labs
some of them I suspect are already fixed all has to be done is to be updated... for sure some fixes are in home folders of people already...
Alin
On Sat, 30 Apr 2011, Jiri Slaby wrote:
On 04/30/2011 09:32 AM, Alin Marin Elena wrote:
here it is the list with packages that still fail to build with 4.6 from factory. https://build.opensuse.org/project/monitor?project=openSUSE%3AFactory%3AStag...
Thank people who did that. Many of them are -Werror + -Wunused-but-set problem. That should be easy to fix (but obviously needs man-hours).
See also home:rguenther:plygrnd in IBS (full factory re-builds with (more current) GCC 4.6).
Richard.
On Fri, 29 Apr 2011, Jeff Mahoney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/29/2011 02:41 PM, Greg Freemyer wrote:
On Fri, Apr 29, 2011 at 11:45 AM, Jeff Mahoney jeffm@suse.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi all -
I know someone else mentioned this briefly WRT to Tumbleweed, but I'd like to bring up for discussion the adoption of gcc 4.6 for Factory.
<snipped a lot of good stuff about why a kernel compile with gcc 4.6 is a good thing>
Jeff,
I don't have factory running anywhere, but I thought gcc 4.6 was in factory now, but not as default.
You have to invoke it as gcc46 was my understanding.
Would updating the specfile to use gcc46 instead of gcc be feasible until the default gcc is updated?
Yeah, that'd be pretty easy. The hard part comes in when you want to build KMPs against that kernel since they won't be using the same compiler version unless they're *also* modified to use CC=gcc-4.6
Well, it's coolos call, but I won't mind switching to GCC 4.6 by default for Factory.
Richard.
On 05/02/2011 10:37 AM, Richard Guenther wrote: [...]
Well, it's coolos call, but I won't mind switching to GCC 4.6 by default for Factory.
I suggest we wait at least until the packages under staging are fixed.
Regards.
On Mon, 2 May 2011, Ismail Dönmez wrote:
On 05/02/2011 10:37 AM, Richard Guenther wrote: [...]
Well, it's coolos call, but I won't mind switching to GCC 4.6 by default for Factory.
I suggest we wait at least until the packages under staging are fixed.
Past experience tells that there is at most asymptotic convergence to that unless somebody steps in and does all the work (I've been doing a lot of that for getting 4.5 in, so has coolo).
Richard.
On 05/02/2011 10:54 AM, Richard Guenther wrote:
On Mon, 2 May 2011, Ismail Dönmez wrote:
On 05/02/2011 10:37 AM, Richard Guenther wrote: [...]
Well, it's coolos call, but I won't mind switching to GCC 4.6 by default for Factory.
I suggest we wait at least until the packages under staging are fixed.
Past experience tells that there is at most asymptotic convergence to that unless somebody steps in and does all the work (I've been doing a lot of that for getting 4.5 in, so has coolo).
I myself fixed many gcc 4.6 problems, some are still not submitted to Factory from their devel packages. Maybe we should just enable gcc 4.6 and expect people to fix it.
Currently I wait for days before even an SR gets looked at because its a non-issue atm.
Regards.
On Mon, 2 May 2011 10:54:41 +0200 (CEST) Richard Guenther rguenther@suse.de wrote:
On Mon, 2 May 2011, Ismail Dönmez wrote:
I suggest we wait at least until the packages under staging are fixed.
Past experience tells that there is at most asymptotic convergence to that unless somebody steps in and does all the work (I've been doing a lot of that for getting 4.5 in, so has coolo).
One problem is that openSUSE:Factory:Staging:Gcc46 is outdated (I fixed and submitrequested NetworkManager-gnome, but it is much older than the one in the devel project, so the usefulness of that fix is to be questioned). And that submitrequest (68894) has not been accepted yet (which might in this case be the correct thing to do).
This I'm reluctant to invest more time in obviously obsolete work.
On 05/02/2011 11:36 AM, Stefan Seyfried wrote:
On Mon, 2 May 2011 10:54:41 +0200 (CEST) Richard Guentherrguenther@suse.de wrote:
On Mon, 2 May 2011, Ismail Dönmez wrote:
I suggest we wait at least until the packages under staging are fixed.
Past experience tells that there is at most asymptotic convergence to that unless somebody steps in and does all the work (I've been doing a lot of that for getting 4.5 in, so has coolo).
One problem is that openSUSE:Factory:Staging:Gcc46 is outdated (I fixed and submitrequested NetworkManager-gnome, but it is much older than the one in the devel project, so the usefulness of that fix is to be questioned). And that submitrequest (68894) has not been accepted yet (which might in this case be the correct thing to do).
This I'm reluctant to invest more time in obviously obsolete work.
Upstream fixed NetworkManager problem by disabling the write-only variable warning. I guess it'll come via Gnome 3.0 work.
Regards.
Am Montag, 2. Mai 2011 schrieb Stefan Seyfried:
On Mon, 2 May 2011 10:54:41 +0200 (CEST)
Richard Guenther rguenther@suse.de wrote:
On Mon, 2 May 2011, Ismail Dönmez wrote:
I suggest we wait at least until the packages under staging are fixed.
Past experience tells that there is at most asymptotic convergence to that unless somebody steps in and does all the work (I've been doing a lot of that for getting 4.5 in, so has coolo).
One problem is that openSUSE:Factory:Staging:Gcc46 is outdated (I fixed and submitrequested NetworkManager-gnome, but it is much older than the one in the devel project, so the usefulness of that fix is to be questioned). And that submitrequest (68894) has not been accepted yet (which might in this case be the correct thing to do).
Submitting it to :Gcc46 is indeed pointless, it should be fixed in the devel project.
Greetings, Stephan
On 05/02/2011 12:02 PM, Stephan Kulow wrote:
Am Montag, 2. Mai 2011 schrieb Stefan Seyfried:
On Mon, 2 May 2011 10:54:41 +0200 (CEST)
Richard Guenther rguenther@suse.de wrote:
On Mon, 2 May 2011, Ismail Dönmez wrote:
I suggest we wait at least until the packages under staging are fixed.
Past experience tells that there is at most asymptotic convergence to that unless somebody steps in and does all the work (I've been doing a lot of that for getting 4.5 in, so has coolo).
One problem is that openSUSE:Factory:Staging:Gcc46 is outdated (I fixed and submitrequested NetworkManager-gnome, but it is much older than the one in the devel project, so the usefulness of that fix is to be questioned). And that submitrequest (68894) has not been accepted yet (which might in this case be the correct thing to do).
Submitting it to :Gcc46 is indeed pointless, it should be fixed in the devel project.
Looks like we are under 90 now, will go even lower when some of the SRs are resolved. Maybe we should think about switching to gcc 4.6 after 12.1 Milestone 1?
Regards.
Am Mittwoch, 4. Mai 2011, 18:16:10 schrieb Ismail Dönmez:
On 05/02/2011 12:02 PM, Stephan Kulow wrote:
Am Montag, 2. Mai 2011 schrieb Stefan Seyfried:
On Mon, 2 May 2011 10:54:41 +0200 (CEST)
Richard Guenther rguenther@suse.de wrote:
On Mon, 2 May 2011, Ismail Dönmez wrote:
I suggest we wait at least until the packages under staging are fixed.
Past experience tells that there is at most asymptotic convergence to that unless somebody steps in and does all the work (I've been doing a lot of that for getting 4.5 in, so has coolo).
One problem is that openSUSE:Factory:Staging:Gcc46 is outdated (I fixed and submitrequested NetworkManager-gnome, but it is much older than the one in the devel project, so the usefulness of that fix is to be questioned). And that submitrequest (68894) has not been accepted yet (which might in this case be the correct thing to do).
Submitting it to :Gcc46 is indeed pointless, it should be fixed in the devel project.
Looks like we are under 90 now, will go even lower when some of the SRs are resolved. Maybe we should think about switching to gcc 4.6 after 12.1 Milestone 1?
I'm actually thinking about doing it once GNOME3 is in - and let it all rebuild over Linuxtag with gcc46 and then release M1
Greetings, Stephan
Am Wed 04 May 2011 09:05:35 PM CEST schrieb Stephan Kulow coolo@novell.com:
Am Mittwoch, 4. Mai 2011, 18:16:10 schrieb Ismail Dönmez:
On 05/02/2011 12:02 PM, Stephan Kulow wrote:
Am Montag, 2. Mai 2011 schrieb Stefan Seyfried:
On Mon, 2 May 2011 10:54:41 +0200 (CEST)
Richard Guenther rguenther@suse.de wrote:
On Mon, 2 May 2011, Ismail Dönmez wrote:
I suggest we wait at least until the packages under staging are fixed.
Past experience tells that there is at most asymptotic convergence to that unless somebody steps in and does all the work (I've been doing a lot of that for getting 4.5 in, so has coolo).
One problem is that openSUSE:Factory:Staging:Gcc46 is outdated (I fixed and submitrequested NetworkManager-gnome, but it is much older than the one in the devel project, so the usefulness of that fix is to be questioned). And that submitrequest (68894) has not been accepted yet (which might in this case be the correct thing to do).
Submitting it to :Gcc46 is indeed pointless, it should be fixed in the devel project.
Looks like we are under 90 now, will go even lower when some of the SRs are resolved. Maybe we should think about switching to gcc 4.6 after 12.1 Milestone 1?
I'm actually thinking about doing it once GNOME3 is in - and let it all rebuild over Linuxtag with gcc46 and then release M1
Sounds perfect :-)
On 05/04/2011 09:05 PM, Stephan Kulow wrote:
I'm actually thinking about doing it once GNOME3 is in - and let it all rebuild over Linuxtag with gcc46 and then release M1
FWIW debian unstable has gcc46 as a default compiler since the past week: http://www.linuxinsight.com/debian-wheezy-gcc-4.6-now-default.html
regards,
On Wed, 4 May 2011, Jiri Slaby wrote:
On 05/04/2011 09:05 PM, Stephan Kulow wrote:
I'm actually thinking about doing it once GNOME3 is in - and let it all rebuild over Linuxtag with gcc46 and then release M1
FWIW debian unstable has gcc46 as a default compiler since the past week: http://www.linuxinsight.com/debian-wheezy-gcc-4.6-now-default.html
Fedora has it since some months already. So as we're not first this time (we were with 4.5) I don't expect much surprises (and we're close to releasing 4.6.1 already).
Richard.
On 04/29/2011 08:41 PM, Greg Freemyer wrote:
On Fri, Apr 29, 2011 at 11:45 AM, Jeff Mahoneyjeffm@suse.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi all -
I know someone else mentioned this briefly WRT to Tumbleweed, but I'd like to bring up for discussion the adoption of gcc 4.6 for Factory.
<snipped a lot of good stuff about why a kernel compile with gcc 4.6 is a good thing>
Jeff,
I don't have factory running anywhere, but I thought gcc 4.6 was in factory now, but not as default.
You have to invoke it as gcc46 was my understanding.
Would updating the specfile to use gcc46 instead of gcc be feasible until the default gcc is updated?
Greg
You can add a gcc46 repository by : a) In project repositories: add repositories -> pick one via advanced interface -> devel:gcc:gcc46/openSUSE_Factory. b) osc meta prj -e <nameofproect> -> add the following : <repository name="gcc46_openSUSE_Factory"> <path project="devel:gcc:gcc46" repository="openSUSE_Factory"/> <arch>x86_64</arch> <arch>i586</arch> </repository> I've had one in my home ever since I saw it in KDF last year and also added one to multimedia:apps/libs, it's a good way of fixing problems before they become problems. Most failures need a "#include <something from glibc>" added.
Dave P
-
Alin Marin Elena -
Dave Plater -
Greg Freemyer -
Ismail Doenmez -
Ismail Dönmez
-
Jeff Mahoney -
Jiri Slaby -
Michal Marek -
Peter Linnell -
Richard Guenther -
Stefan Seyfried -
Stephan Kulow