[opensuse-kernel] CONFIG_CC_STACKPROTECTOR
Hi! I'm wondering why CONFIG_CC_STACKPROTECTOR is disabled on openSUSE. Debian and Fedora seem to enabled it per default. What's the deal? -- Thanks, //richard -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Sat, Jun 30, 2012 at 07:05:20PM +0200, richard -rw- weinberger wrote:
Hi!
I'm wondering why CONFIG_CC_STACKPROTECTOR is disabled on openSUSE. Debian and Fedora seem to enabled it per default.
What's the deal?
We had it enabled once, but in the CONFIG_CC_STACKPROTECTOR_ALL mode, which caused speed regressions. Solution apparently was to disable it completely. I think we can enable the non-all version without speed-loss. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Le lundi 02 juillet 2012 à 00:37 +0200, Marcus Meissner a écrit :
On Sat, Jun 30, 2012 at 07:05:20PM +0200, richard -rw- weinberger wrote:
Hi!
I'm wondering why CONFIG_CC_STACKPROTECTOR is disabled on openSUSE. Debian and Fedora seem to enabled it per default.
What's the deal?
We had it enabled once, but in the CONFIG_CC_STACKPROTECTOR_ALL mode, which caused speed regressions.
Solution apparently was to disable it completely.
Meanwhile, upstream killed CONFIG_CC_STACKPROTECTOR_ALL. It happened in kernel 2.6.32 with comment: x86: Remove STACKPROTECTOR_ALL STACKPROTECTOR_ALL has a really high overhead (runtime and stack footprint) and is not really worth it protection wise (the normal STACKPROTECTOR is in effect for all functions with buffers already), so lets just remove the option entirely.
I think we can enable the non-all version without speed-loss.
I am worried that the option is still marked as experimental, but maybe it was just overlooked. I'll bring the topic up for upstream discussion. -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Le mardi 03 juillet 2012 à 09:38 +0200, Jean Delvare a écrit :
Le lundi 02 juillet 2012 à 00:37 +0200, Marcus Meissner a écrit :
On Sat, Jun 30, 2012 at 07:05:20PM +0200, richard -rw- weinberger wrote:
Hi!
I'm wondering why CONFIG_CC_STACKPROTECTOR is disabled on openSUSE. Debian and Fedora seem to enabled it per default.
What's the deal?
We had it enabled once, but in the CONFIG_CC_STACKPROTECTOR_ALL mode, which caused speed regressions.
Solution apparently was to disable it completely.
Meanwhile, upstream killed CONFIG_CC_STACKPROTECTOR_ALL. It happened in kernel 2.6.32 with comment:
x86: Remove STACKPROTECTOR_ALL
STACKPROTECTOR_ALL has a really high overhead (runtime and stack footprint) and is not really worth it protection wise (the normal STACKPROTECTOR is in effect for all functions with buffers already), so lets just remove the option entirely.
I think we can enable the non-all version without speed-loss.
I am worried that the option is still marked as experimental, but maybe it was just overlooked. I'll bring the topic up for upstream discussion.
Result from upstream discussion is that CC_STACKPROTECTOR is no longer considered an experimental feature on x86. That being said, we already have CONFIG_CC_STACKPROTECTOR=y in debug kernels. This led me to investigating the reasons and I found this commit: commit b4df61d63c69c3d83b5dbf8a9929d9a5022a4027 Author: Nick Piggin <npiggin@suse.de> Date: Tue Nov 10 16:24:00 2009 +1100 - Update config files. Disable CONFIG_CC_STACKPROTECTOR on all x86 kernels except debug. Overhead is prohibitive. So it was done on purpose. And the interesting detail is that CONFIG_CC_STACKPROTECTOR_ALL had already been dropped at that time. That was recent though (3 weeks), so it's not clear to me if Nick had tested with or without CONFIG_CC_STACKPROTECTOR_ALL. OTOH Arjan van de Ven just confirmed on LKML that CONFIG_CC_STACKPROTECTOR had been enabled on distribution kernels for years, so I presume the performance issues are history now, and we can do the same in all our kernels. So, unless someone objects by then, I'll set CONFIG_CC_STACKPROTECTOR=y in i386 and x86_64 kernels tomorrow. -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/9/12 10:37 AM, Jean Delvare wrote:
Le mardi 03 juillet 2012 à 09:38 +0200, Jean Delvare a écrit :
Le lundi 02 juillet 2012 à 00:37 +0200, Marcus Meissner a écrit :
On Sat, Jun 30, 2012 at 07:05:20PM +0200, richard -rw- weinberger wrote:
Hi!
I'm wondering why CONFIG_CC_STACKPROTECTOR is disabled on openSUSE. Debian and Fedora seem to enabled it per default.
What's the deal?
We had it enabled once, but in the CONFIG_CC_STACKPROTECTOR_ALL mode, which caused speed regressions.
Solution apparently was to disable it completely.
Meanwhile, upstream killed CONFIG_CC_STACKPROTECTOR_ALL. It happened in kernel 2.6.32 with comment:
x86: Remove STACKPROTECTOR_ALL
STACKPROTECTOR_ALL has a really high overhead (runtime and stack footprint) and is not really worth it protection wise (the normal STACKPROTECTOR is in effect for all functions with buffers already), so lets just remove the option entirely.
I think we can enable the non-all version without speed-loss.
I am worried that the option is still marked as experimental, but maybe it was just overlooked. I'll bring the topic up for upstream discussion.
Result from upstream discussion is that CC_STACKPROTECTOR is no longer considered an experimental feature on x86.
That being said, we already have CONFIG_CC_STACKPROTECTOR=y in debug kernels. This led me to investigating the reasons and I found this commit:
commit b4df61d63c69c3d83b5dbf8a9929d9a5022a4027 Author: Nick Piggin <npiggin@suse.de> Date: Tue Nov 10 16:24:00 2009 +1100
- Update config files. Disable CONFIG_CC_STACKPROTECTOR on all x86 kernels except debug. Overhead is prohibitive.
So it was done on purpose. And the interesting detail is that CONFIG_CC_STACKPROTECTOR_ALL had already been dropped at that time. That was recent though (3 weeks), so it's not clear to me if Nick had tested with or without CONFIG_CC_STACKPROTECTOR_ALL.
OTOH Arjan van de Ven just confirmed on LKML that CONFIG_CC_STACKPROTECTOR had been enabled on distribution kernels for years, so I presume the performance issues are history now, and we can do the same in all our kernels.
So, unless someone objects by then, I'll set CONFIG_CC_STACKPROTECTOR=y in i386 and x86_64 kernels tomorrow.
Thanks for looking into this, Jean. Since we don't have a bnc in the commit log to see what the performance degradation looked like originally, I'd like to see some analysis now to actually confirm whether it makes a difference anymore. openSUSE 12.2 was supposed to be released in two days time but was delayed due to too much churn (among other things). If there is a performance difference, I'd prefer to know about it before we do the change rather than depend on post-release bug reports and the accompanying hand-wringing over whether to revert it. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJP+u5OAAoJEB57S2MheeWyKfkP/29kJnAbfxxo5swkwHuok5Ak ayEa/arQ8QxKHsgeOsFBu/1oXlhqIDHImw4A6qJALP7881GP1O7sp7ICgaxWgwuO FhmHxy0UDS07rfiTuU6VHRK25022ZJgeLR2YHaU0oEsiVRX6IzJ9BN/VqYGzXeHA RAlBhSts42aQ5loql6MdMmO/ae4sm0ses8Vh85xROyEjssLNn6fP7t5lweVPuKCa H7rXq1nr1mRSKgYJXqkes1Ksjc2oP9esXMW/R50A2YRU1kBdf6BPsnMcz20MNQCw BusJslHd6dYoH3lSPD+cyi3IdDDKWNEQbZKlZ8KQbN0v8pJ4bUm7VdfBLlPP3SeQ s/gKIjFUOr1Rsy163pWcwiWXoIg7obTt0BJ3FzBxKevng5hADvo0NNo2zd/MlSBG MDDTVAsg6ojn4Y2czxsyMfF9/4NPtJ7xFiCEftqmeUu8pSf2BcQhaSZXUOktXOm1 GJLCpjl5+B52ajiXuqjGT5jwC1ZGAyoFYxyOIgnqoNOcwL7eCwJV+ZrSiIzT6IdI zQ5vOH3np1gs6Z7I2PPvY/OR9LKk0hJ84nTDI1y5xFpfp/BtkXbeyXrUoqpvJMjf Sepkf1d0w5+2zhoIXu/kqULrvBGH9Rx2nuPY2CE7MIHAGEZmCTay0kyRe/CJPU8T /9NpHcSWl2J7o/XQKuG0 =362Q -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Le lundi 09 juillet 2012 à 10:44 -0400, Jeff Mahoney a écrit :
On 7/9/12 10:37 AM, Jean Delvare wrote:
So, unless someone objects by then, I'll set CONFIG_CC_STACKPROTECTOR=y in i386 and x86_64 kernels tomorrow.
Thanks for looking into this, Jean. Since we don't have a bnc in the commit log to see what the performance degradation looked like originally, I'd like to see some analysis now to actually confirm whether it makes a difference anymore.
openSUSE 12.2 was supposed to be released in two days time but was delayed due to too much churn (among other things). If there is a performance difference, I'd prefer to know about it before we do the change rather than depend on post-release bug reports and the accompanying hand-wringing over whether to revert it.
Are you simply suggesting that I should change the configuration for master only and not the openSUSE-12.2 branch? Or should I wait even for master? I admit I'm not sure how to test for performance regression. With CONFIG_CC_STACKPROTECTOR_ALL it was relatively obvious, but now that only selected functions get the protection, I can imagine that the performance hit completely depends on the drivers, filesystem etc. in use. It might be easier to check what other distributions are doing, and simply align on that. Richard said that Debian and Fedora "seemed" to enable it by default, it would have to be confirmed, and ideally Ubuntu and RHEL should be checked as well. Unfortunately I don't have any of these at home so I can't check. -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/9/12 3:07 PM, Jean Delvare wrote:
Le lundi 09 juillet 2012 à 10:44 -0400, Jeff Mahoney a écrit :
On 7/9/12 10:37 AM, Jean Delvare wrote:
So, unless someone objects by then, I'll set CONFIG_CC_STACKPROTECTOR=y in i386 and x86_64 kernels tomorrow.
Thanks for looking into this, Jean. Since we don't have a bnc in the commit log to see what the performance degradation looked like originally, I'd like to see some analysis now to actually confirm whether it makes a difference anymore.
openSUSE 12.2 was supposed to be released in two days time but was delayed due to too much churn (among other things). If there is a performance difference, I'd prefer to know about it before we do the change rather than depend on post-release bug reports and the accompanying hand-wringing over whether to revert it.
Are you simply suggesting that I should change the configuration for master only and not the openSUSE-12.2 branch? Or should I wait even for master?
I admit I'm not sure how to test for performance regression. With CONFIG_CC_STACKPROTECTOR_ALL it was relatively obvious, but now that only selected functions get the protection, I can imagine that the performance hit completely depends on the drivers, filesystem etc. in use.
A quick look makes it seem like it really only has an effect during context switch. Mike - What would you use to test this? - -Jeff
It might be easier to check what other distributions are doing, and simply align on that. Richard said that Debian and Fedora "seemed" to enable it by default, it would have to be confirmed, and ideally Ubuntu and RHEL should be checked as well. Unfortunately I don't have any of these at home so I can't check.
- -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJP+y/bAAoJEB57S2MheeWyv3wP/RRT9N1gnZxGcfXLmq7/dmuP ZPLgnxDzNvHNVt3ZhgQQtb3rbjUUhozMQ45oBFr5fB3uwiyQ/axE4iBc/+T2qMQS GQZrWv1qHcvTkLXnYVQdSKW/tj8OG4HsSPXLZsVFSCj15NNTmAhE9SJpB3+fGRM1 PG1IJght5AO7SjUsSajgtJnUoQMGQByZq2Q1Pv3UA73L8hn1pHY29O27o1PLYZQ9 DaVND8mJwc7lh0fZxM5v4OIKVnIbLscsa2pBpBpLqoVDuAwAKKbFu1UxrrFte44L sIQzQjFH/hQbpWWI2yd1MYcd9gKQ7P674gUlSy2T7fSIG5RREwJWnN3ajyk7/jhm BK3ihXvu3krZSX+3rA+Bo5hQg58IClZxat6N1rDpdob/lUuqYswnwR/ujl8Jxjb4 TzwNyrKkyfEQUeJzKGStjrAh4DczE5IPfOrAfDDHiHWKlzGpI466nqGxJly/saK6 FX0aKjB56j8T/k8KCETIEdMSO+Qsm06DPGKmOhpEJqJkPjnUXA26FxAoQgiatfYV RKJOtSJiBjpILfDSDMdie450B0BFds2BFwr/QdOAxokwWPHRG1r+487Lnpgd2F+3 EABii5mtODrq88MBlMokk68oYUgB6WilwFjXUxsTbEBl6X3LMNzU3pbiaEFvgZQ+ MJC/zTJKYrk1msStMn+O =oHYA -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Mon, 2012-07-09 at 15:24 -0400, Jeff Mahoney wrote:
On 7/9/12 3:07 PM, Jean Delvare wrote:
Le lundi 09 juillet 2012 à 10:44 -0400, Jeff Mahoney a écrit :
On 7/9/12 10:37 AM, Jean Delvare wrote:
So, unless someone objects by then, I'll set CONFIG_CC_STACKPROTECTOR=y in i386 and x86_64 kernels tomorrow.
Thanks for looking into this, Jean. Since we don't have a bnc in the commit log to see what the performance degradation looked like originally, I'd like to see some analysis now to actually confirm whether it makes a difference anymore.
openSUSE 12.2 was supposed to be released in two days time but was delayed due to too much churn (among other things). If there is a performance difference, I'd prefer to know about it before we do the change rather than depend on post-release bug reports and the accompanying hand-wringing over whether to revert it.
Are you simply suggesting that I should change the configuration for master only and not the openSUSE-12.2 branch? Or should I wait even for master?
I admit I'm not sure how to test for performance regression. With CONFIG_CC_STACKPROTECTOR_ALL it was relatively obvious, but now that only selected functions get the protection, I can imagine that the performance hit completely depends on the drivers, filesystem etc. in use.
A quick look makes it seem like it really only has an effect during context switch.
Mike - What would you use to test this?
A pinned fork()/sched_yield() pair for pure context switch. -Mike -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Reviving an old thread... Le Tuesday 10 July 2012 à 05:42 +0200, Mike Galbraith a écrit :
On Mon, 2012-07-09 at 15:24 -0400, Jeff Mahoney wrote:
On 7/9/12 3:07 PM, Jean Delvare wrote:
Le lundi 09 juillet 2012 à 10:44 -0400, Jeff Mahoney a écrit :
On 7/9/12 10:37 AM, Jean Delvare wrote:
So, unless someone objects by then, I'll set CONFIG_CC_STACKPROTECTOR=y in i386 and x86_64 kernels tomorrow.
Thanks for looking into this, Jean. Since we don't have a bnc in the commit log to see what the performance degradation looked like originally, I'd like to see some analysis now to actually confirm whether it makes a difference anymore.
openSUSE 12.2 was supposed to be released in two days time but was delayed due to too much churn (among other things). If there is a performance difference, I'd prefer to know about it before we do the change rather than depend on post-release bug reports and the accompanying hand-wringing over whether to revert it.
Are you simply suggesting that I should change the configuration for master only and not the openSUSE-12.2 branch? Or should I wait even for master?
I admit I'm not sure how to test for performance regression. With CONFIG_CC_STACKPROTECTOR_ALL it was relatively obvious, but now that only selected functions get the protection, I can imagine that the performance hit completely depends on the drivers, filesystem etc. in use.
A quick look makes it seem like it really only has an effect during context switch.
Mike - What would you use to test this?
A pinned fork()/sched_yield() pair for pure context switch.
I have absolutely no idea how I would actually test that in practice, sorry. OTOH I looked at Fedora [1], Red Hat [2], Slackware [3], Debian [4] and Ubuntu [5], they all have CONFIG_CC_STACKPROTECTOR=y. I can't imagine everyone else would have enabled this option if it caused a significant performance hit. So I'm going to enable this option in the Factory kernel right now, on all architectures which support it. [1] http://archive.fedoraproject.org/pub/fedora/linux/releases/18/Fedora/source/... [2] http://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/SRPMS/kernel... [3] http://mirrors.dotsrc.org/slackware/slackware/source/k/config-x86/ [4] http://ftp.de.debian.org/debian/pool/main/l/linux/linux_3.2.41-2.debian.tar.... [5] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/369152 -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Sun, 2013-05-05 at 09:44 +0200, Jean Delvare wrote:
Reviving an old thread...
Le Tuesday 10 July 2012 à 05:42 +0200, Mike Galbraith a écrit :
On Mon, 2012-07-09 at 15:24 -0400, Jeff Mahoney wrote:
On 7/9/12 3:07 PM, Jean Delvare wrote:
Le lundi 09 juillet 2012 à 10:44 -0400, Jeff Mahoney a écrit :
On 7/9/12 10:37 AM, Jean Delvare wrote:
So, unless someone objects by then, I'll set CONFIG_CC_STACKPROTECTOR=y in i386 and x86_64 kernels tomorrow.
Thanks for looking into this, Jean. Since we don't have a bnc in the commit log to see what the performance degradation looked like originally, I'd like to see some analysis now to actually confirm whether it makes a difference anymore.
openSUSE 12.2 was supposed to be released in two days time but was delayed due to too much churn (among other things). If there is a performance difference, I'd prefer to know about it before we do the change rather than depend on post-release bug reports and the accompanying hand-wringing over whether to revert it.
Are you simply suggesting that I should change the configuration for master only and not the openSUSE-12.2 branch? Or should I wait even for master?
I admit I'm not sure how to test for performance regression. With CONFIG_CC_STACKPROTECTOR_ALL it was relatively obvious, but now that only selected functions get the protection, I can imagine that the performance hit completely depends on the drivers, filesystem etc. in use.
A quick look makes it seem like it really only has an effect during context switch.
Mike - What would you use to test this?
A pinned fork()/sched_yield() pair for pure context switch.
I have absolutely no idea how I would actually test that in practice, sorry.
I measured tbench, sched_yield and AIM7 compute on monteverdi with 3.9.0, and see diddly spit difference outside boot to boot and build to build variance.
OTOH I looked at Fedora [1], Red Hat [2], Slackware [3], Debian [4] and Ubuntu [5], they all have CONFIG_CC_STACKPROTECTOR=y. I can't imagine everyone else would have enabled this option if it caused a significant performance hit.
So I'm going to enable this option in the Factory kernel right now, on all architectures which support it.
[1] http://archive.fedoraproject.org/pub/fedora/linux/releases/18/Fedora/source/... [2] http://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/SRPMS/kernel... [3] http://mirrors.dotsrc.org/slackware/slackware/source/k/config-x86/ [4] http://ftp.de.debian.org/debian/pool/main/l/linux/linux_3.2.41-2.debian.tar.... [5] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/369152
-- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Le Monday 06 May 2013 à 11:50 +0200, Mike Galbraith a écrit :
On Sun, 2013-05-05 at 09:44 +0200, Jean Delvare wrote:
Reviving an old thread...
Le Tuesday 10 July 2012 à 05:42 +0200, Mike Galbraith a écrit :
On Mon, 2012-07-09 at 15:24 -0400, Jeff Mahoney wrote:
A quick look makes it seem like it really only has an effect during context switch.
Mike - What would you use to test this?
A pinned fork()/sched_yield() pair for pure context switch.
I have absolutely no idea how I would actually test that in practice, sorry.
I measured tbench, sched_yield and AIM7 compute on monteverdi with 3.9.0, and see diddly spit difference outside boot to boot and build to build variance.
Thanks Mike, this was helpful! So I think we're good to go with the committed change. -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Hi again Mike, Le Monday 06 May 2013 à 11:50 +0200, Mike Galbraith a écrit :
I measured tbench, sched_yield and AIM7 compute on monteverdi with 3.9.0, and see diddly spit difference outside boot to boot and build to build variance.
I took a closer look at the code and it seems that i386 may suffer from a greater performance hit than x86_64. This is because enabling CONFIG_CC_STACKPROTECTOR on i386 disables X86_32_LAZY_GS. I am not familiar with the details but I seem to understand it's about a performance optimization of how context switches are handled. I have no idea how significant it is in practice. Would you be able to do the performance test again but on a 32-bit x86 host? Thanks, -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Tue, 2013-05-14 at 15:18 +0200, Jean Delvare wrote:
Hi again Mike,
Le Monday 06 May 2013 à 11:50 +0200, Mike Galbraith a écrit :
I measured tbench, sched_yield and AIM7 compute on monteverdi with 3.9.0, and see diddly spit difference outside boot to boot and build to build variance.
I took a closer look at the code and it seems that i386 may suffer from a greater performance hit than x86_64. This is because enabling CONFIG_CC_STACKPROTECTOR on i386 disables X86_32_LAZY_GS. I am not familiar with the details but I seem to understand it's about a performance optimization of how context switches are handled. I have no idea how significant it is in practice.
Would you be able to do the performance test again but on a 32-bit x86 host?
Sure. Can it wait a bit? (want to get rt merges/test done first) -Mike -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Le Wednesday 15 May 2013 à 06:41 +0200, Mike Galbraith a écrit :
On Tue, 2013-05-14 at 15:18 +0200, Jean Delvare wrote:
Hi again Mike,
Le Monday 06 May 2013 à 11:50 +0200, Mike Galbraith a écrit :
I measured tbench, sched_yield and AIM7 compute on monteverdi with 3.9.0, and see diddly spit difference outside boot to boot and build to build variance.
I took a closer look at the code and it seems that i386 may suffer from a greater performance hit than x86_64. This is because enabling CONFIG_CC_STACKPROTECTOR on i386 disables X86_32_LAZY_GS. I am not familiar with the details but I seem to understand it's about a performance optimization of how context switches are handled. I have no idea how significant it is in practice.
Would you be able to do the performance test again but on a 32-bit x86 host?
Sure. Can it wait a bit? (want to get rt merges/test done first)
No problem, we have some time left before openSUSE 13.1 is released. Thanks, -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Hi Mike, Reviving an old thread... Le Thursday 16 May 2013 à 09:11 +0200, Jean Delvare a écrit :
Le Wednesday 15 May 2013 à 06:41 +0200, Mike Galbraith a écrit :
On Tue, 2013-05-14 at 15:18 +0200, Jean Delvare wrote:
I took a closer look at the code and it seems that i386 may suffer from a greater performance hit than x86_64. This is because enabling CONFIG_CC_STACKPROTECTOR on i386 disables X86_32_LAZY_GS. I am not familiar with the details but I seem to understand it's about a performance optimization of how context switches are handled. I have no idea how significant it is in practice.
Would you be able to do the performance test again but on a 32-bit x86 host?
Sure. Can it wait a bit? (want to get rt merges/test done first)
No problem, we have some time left before openSUSE 13.1 is released.
13.1 is out by now ;-) Out of curiosity, did you ever find the time to perform the benchmark on 32-bit x86? Thanks, -- Jean Delvare Suse L3 Support -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Thu, 2013-12-12 at 09:09 +0100, Jean Delvare wrote:
Hi Mike,
Reviving an old thread...
Le Thursday 16 May 2013 à 09:11 +0200, Jean Delvare a écrit :
Le Wednesday 15 May 2013 à 06:41 +0200, Mike Galbraith a écrit :
On Tue, 2013-05-14 at 15:18 +0200, Jean Delvare wrote:
I took a closer look at the code and it seems that i386 may suffer from a greater performance hit than x86_64. This is because enabling CONFIG_CC_STACKPROTECTOR on i386 disables X86_32_LAZY_GS. I am not familiar with the details but I seem to understand it's about a performance optimization of how context switches are handled. I have no idea how significant it is in practice.
Would you be able to do the performance test again but on a 32-bit x86 host?
Sure. Can it wait a bit? (want to get rt merges/test done first)
No problem, we have some time left before openSUSE 13.1 is released.
13.1 is out by now ;-) Out of curiosity, did you ever find the time to perform the benchmark on 32-bit x86?
Oh, no, forgot all about that. Jiri had a double sided DVD send (download takes a week minimum here), but it had a white spot on one side.. guess which. Trying to remove it and polish the disk.. well, it lived on under my coffee cup for a while :) -Mike -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
At Thu, 12 Dec 2013 09:53:12 +0100, Mike Galbraith wrote:
On Thu, 2013-12-12 at 09:09 +0100, Jean Delvare wrote:
Hi Mike,
Reviving an old thread...
Le Thursday 16 May 2013 à 09:11 +0200, Jean Delvare a écrit :
Le Wednesday 15 May 2013 à 06:41 +0200, Mike Galbraith a écrit :
On Tue, 2013-05-14 at 15:18 +0200, Jean Delvare wrote:
I took a closer look at the code and it seems that i386 may suffer from a greater performance hit than x86_64. This is because enabling CONFIG_CC_STACKPROTECTOR on i386 disables X86_32_LAZY_GS. I am not familiar with the details but I seem to understand it's about a performance optimization of how context switches are handled. I have no idea how significant it is in practice.
Would you be able to do the performance test again but on a 32-bit x86 host?
Sure. Can it wait a bit? (want to get rt merges/test done first)
No problem, we have some time left before openSUSE 13.1 is released.
13.1 is out by now ;-) Out of curiosity, did you ever find the time to perform the benchmark on 32-bit x86?
Oh, no, forgot all about that. Jiri had a double sided DVD send (download takes a week minimum here),
So a pigeon flying from Nuremberg might have a better bandwidth and latency :) Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Fri, 2013-12-13 at 15:38 +0100, Takashi Iwai wrote:
At Thu, 12 Dec 2013 09:53:12 +0100, Mike Galbraith wrote:
On Thu, 2013-12-12 at 09:09 +0100, Jean Delvare wrote:
Hi Mike,
Reviving an old thread...
Le Thursday 16 May 2013 à 09:11 +0200, Jean Delvare a écrit :
Le Wednesday 15 May 2013 à 06:41 +0200, Mike Galbraith a écrit :
On Tue, 2013-05-14 at 15:18 +0200, Jean Delvare wrote:
I took a closer look at the code and it seems that i386 may suffer from a greater performance hit than x86_64. This is because enabling CONFIG_CC_STACKPROTECTOR on i386 disables X86_32_LAZY_GS. I am not familiar with the details but I seem to understand it's about a performance optimization of how context switches are handled. I have no idea how significant it is in practice.
Would you be able to do the performance test again but on a 32-bit x86 host?
Sure. Can it wait a bit? (want to get rt merges/test done first)
No problem, we have some time left before openSUSE 13.1 is released.
13.1 is out by now ;-) Out of curiosity, did you ever find the time to perform the benchmark on 32-bit x86?
Oh, no, forgot all about that. Jiri had a double sided DVD send (download takes a week minimum here),
So a pigeon flying from Nuremberg might have a better bandwidth and latency :)
Pigeon? You could _walk_ the 200km round trip at higher bandwidth. -Mike -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
participants (7)
-
Jean Delvare -
Jeff Mahoney -
Marcus Meissner -
Mike Galbraith -
Mike Galbraith -
richard -rw- weinberger -
Takashi Iwai