I have just done some updates while running 3.8.0-0.rc5.git0.1.fc19. A couple of these machines were booted with slub_debug=- . They all seemed a bit slower (based on my watching the updates and not real benchmarks) than with with the previous debug kernels. It isn't quite to show stopping slow, but it's getting close. It might be the slowness I see with debugging kernels for yum updates, is due to a combination of multiple debugging features rather than a single one.
On Tue, Jan 29, 2013 at 14:53:53 -0600, Bruno Wolff III bruno@wolff.to wrote:
I have just done some updates while running 3.8.0-0.rc5.git0.1.fc19. A couple of these machines were booted with slub_debug=- . They all seemed a bit slower (based on my watching the updates and not real benchmarks) than with with the previous debug kernels. It isn't quite to show stopping slow, but it's getting close. It might be the slowness I see with debugging kernels for yum updates, is due to a combination of multiple debugging features rather than a single one.
Disabling slub debugging at boot time, seems to help speeding up editing preferences in firefox.
On Tue, Jan 29, 2013 at 02:53:53PM -0600, Bruno Wolff III wrote:
I have just done some updates while running 3.8.0-0.rc5.git0.1.fc19. A couple of these machines were booted with slub_debug=- . They all seemed a bit slower (based on my watching the updates and not real benchmarks) than with
Yeah, I had some noticable lag with 3.8.0-0.rc5.git1.1.fc19, which has identical debug options set to the kernel you mentioned. (Rawhide didn't go out yesterday, so I waited to turn more on).
When I booted with slub_debug=- the lag was less, but still noticable. Seems CONFIG_PROVE_RCU might be a heavy hitter. We'll see going forward.
I plan on enabling atomic sleep debugging today. Please keep up the testing and reporting everyone. It's much appreciated.
josh
On Wed, 30 Jan 2013 10:45:53 -0500 Josh Boyer jwboyer@redhat.com wrote:
On Tue, Jan 29, 2013 at 02:53:53PM -0600, Bruno Wolff III wrote:
I have just done some updates while running 3.8.0-0.rc5.git0.1.fc19. A couple of these machines were booted with slub_debug=- . They all seemed a bit slower (based on my watching the updates and not real benchmarks) than with
Yeah, I had some noticable lag with 3.8.0-0.rc5.git1.1.fc19, which has identical debug options set to the kernel you mentioned. (Rawhide didn't go out yesterday, so I waited to turn more on).
When I booted with slub_debug=- the lag was less, but still noticable. Seems CONFIG_PROVE_RCU might be a heavy hitter. We'll see going forward.
I plan on enabling atomic sleep debugging today. Please keep up the testing and reporting everyone. It's much appreciated.
Just finally had a chance to reboot into 3.8.0-0.rc5.git1.1.fc19.x86_64 here.
It's very very very very slow graphically. Also, I note that there's a bunch of disk i/o going on, perhaps btrfs is having some poor interaction with the debugging?
Booting with slub_debug=- brings everything back to usable for me.
It looks like to me slub_debug is the thing that slows things down for my use case. ;)
Happy to keep testing.
kevin
On Wed, Jan 30, 2013 at 10:38:39AM -0700, Kevin Fenzi wrote:
On Wed, 30 Jan 2013 10:45:53 -0500 Josh Boyer jwboyer@redhat.com wrote:
On Tue, Jan 29, 2013 at 02:53:53PM -0600, Bruno Wolff III wrote:
I have just done some updates while running 3.8.0-0.rc5.git0.1.fc19. A couple of these machines were booted with slub_debug=- . They all seemed a bit slower (based on my watching the updates and not real benchmarks) than with
Yeah, I had some noticable lag with 3.8.0-0.rc5.git1.1.fc19, which has identical debug options set to the kernel you mentioned. (Rawhide didn't go out yesterday, so I waited to turn more on).
When I booted with slub_debug=- the lag was less, but still noticable. Seems CONFIG_PROVE_RCU might be a heavy hitter. We'll see going forward.
I plan on enabling atomic sleep debugging today. Please keep up the testing and reporting everyone. It's much appreciated.
Just finally had a chance to reboot into 3.8.0-0.rc5.git1.1.fc19.x86_64 here.
It's very very very very slow graphically. Also, I note that there's a bunch of disk i/o going on, perhaps btrfs is having some poor interaction with the debugging?
Booting with slub_debug=- brings everything back to usable for me.
It looks like to me slub_debug is the thing that slows things down for my use case. ;)
Hm. So that option was the third one enabled. Showed up in 3.8.0-0.rc4.git5.1. Does that specific kernel also cause issues for you?
If not, I'm curious which one starts to because for your usecase it could be a mixture of options causing problems.
josh
On Wed, 30 Jan 2013 12:43:03 -0500 Josh Boyer jwboyer@redhat.com wrote:
On Wed, Jan 30, 2013 at 10:38:39AM -0700, Kevin Fenzi wrote:
On Wed, 30 Jan 2013 10:45:53 -0500 Josh Boyer jwboyer@redhat.com wrote:
On Tue, Jan 29, 2013 at 02:53:53PM -0600, Bruno Wolff III wrote:
I have just done some updates while running 3.8.0-0.rc5.git0.1.fc19. A couple of these machines were booted with slub_debug=- . They all seemed a bit slower (based on my watching the updates and not real benchmarks) than with
Yeah, I had some noticable lag with 3.8.0-0.rc5.git1.1.fc19, which has identical debug options set to the kernel you mentioned. (Rawhide didn't go out yesterday, so I waited to turn more on).
When I booted with slub_debug=- the lag was less, but still noticable. Seems CONFIG_PROVE_RCU might be a heavy hitter. We'll see going forward.
I plan on enabling atomic sleep debugging today. Please keep up the testing and reporting everyone. It's much appreciated.
Just finally had a chance to reboot into 3.8.0-0.rc5.git1.1.fc19.x86_64 here.
It's very very very very slow graphically. Also, I note that there's a bunch of disk i/o going on, perhaps btrfs is having some poor interaction with the debugging?
Booting with slub_debug=- brings everything back to usable for me.
It looks like to me slub_debug is the thing that slows things down for my use case. ;)
Hm. So that option was the third one enabled. Showed up in 3.8.0-0.rc4.git5.1. Does that specific kernel also cause issues for you?
Yeah, that one also shows the slowdown.
If not, I'm curious which one starts to because for your usecase it could be a mixture of options causing problems.
Here's my gtkperf numbers:
3.8.0-0.rc4.git3.1.fc19.x86_64 6.37 3.8.0-0.rc4.git4.1.fc19.x86_64 6.55 3.8.0-0.rc4.git5.1.fc19.x86_64 7.11 3.8.0-0.rc5.git1.1.fc19.x86_64 8.96 3.8.0-0.rc5.git2.1.fc19.x86_64 9.25
with slub-debug=-
3.8.0-0.rc4.git5.1.fc19.x86_64 6.67 3.8.0-0.rc5.git1.1.fc19.x86_64 6.75 3.8.0-0.rc5.git2.1.fc19.x86_64 6.59
kevin
kernel@lists.fedoraproject.org
-
Bruno Wolff III -
Josh Boyer -
Kevin Fenzi