On Wed, 30 Jan 2013 12:43:03 -0500
Josh Boyer <jwboyer(a)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(a)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
Yeah, that one also shows the slowdown.
If not, I'm curious which one starts to because for your usecase
could be a mixture of options causing problems.
Here's my gtkperf numbers: