rawhide slow like a snail because of kernel debugging?

[Michael Schwendt]

On Tue, 12 Feb 2008 16:21:34 +0000, Christopher Brown wrote:

> On 12/02/2008, Michael Schwendt <mschwendt.tmp0701.nospam at arcor.de> wrote:
> > On Tue, 12 Feb 2008 14:41:53 +0000, Christopher Brown wrote:
> >
> > > > It has begun some weeks ago in rawhide and is the same in F9 Alpha,
> > > > which I installed from jigdo CD images.
> > > >
> > > > The entire system is slow whatever it does. Loadavg jumps up
> > > > quickly. When running a simple yum update, loadavg goes above 6. User
> > > > processes don't seem to get as much cpu power as would be possible.
> > > > Windows take seconds to open. The GNOME Desktop is not as responsive
> > > > as in F8 either. Opening dialogs, clicking buttons, there seems to be
> > > > a penalty on everything. It's unbearable. Testing rawhide or F9 is no
> > > > fun at all. Why is this? I remember that during Fedora Core test
> > > > releases various kernel debugging features are enabled. Is this the
> > > > reason also this time? Has it become much more cpu power hungry than
> > > > e.g. with FC7 and older?
> > >
> > > >From the wiki:
> > >
> > > In Rawhide/devel kernels (and in -debug flavors of released kernels),
> > > Fedora uses the SLUB allocator with full slab debugging enabled by
> > > default. The debugging might cause problems in some rare cases: memory
> > > allocations can fail, causing the system to panic. Slab debugging can
> > > be disabled with the option slub_debug=-  (a single minus sign.) Note,
> > > that this option will hide an actual bug that really should be
> > > reported and fixed rather than worked around.
> >
> > Doesn't answer the original question, however.
> 
> I believe it does.

No. See subject. I asked whether any debug options in the kernel are
responsible for the slowdown I experience. You point to a Wiki section
that does _not_ mention any significant slowdown.
 
> > Btw, the thread is longer and contains posts with evidence that X is
> > the culprit.
> 
> No, you started a new thread 

Not true. Changing the subject does not start a new thread, because
the In-Reply-To/References headers are still intact.

> whereas you should've added the info to
> this one or indicated the new thread was a child of this one.
 
The headers do that.