F17 Slowness

[Josh Boyer]

On Thu, Feb 16, 2012 at 4:38 PM, David Malcolm <dmalcolm at redhat.com> wrote:
> My question was about "at runtime": my thinking was that it's useful to
> spell out to the user that they shouldn't expect the final released
> performance from the current system, perhaps adding a message somewhere
> in the UI, so that certain websites who shall remain nameless don't try
> to benchmark the debug builds.
>
> But I just had another variant of this idea: could the string "debug" be
> embedded in the release string of the kernel? (and wire this up in the
> specfile so that it's automatically added)
>
> so e.g.
>  kernel-3.3.0-0.rc3.git6.2.fc18
> would become:
>  kernel-3.3.0-0.rc3.git6.2.debug.fc18
> or
>  kernel-3.3.0-0.rc3.git6.2.fc18.debug
>
> That way it'd show up everywhere e.g. in uname -a, in
> gnome-system-monitor, on logon, etc, and make it obvious that the debug
> code is enabled.
>
> Not sure if this is a good idea or not

We actually already do this.  Sort of.

When we're building release kernels, we actually build kernel and kernel-debug
packages.  The kernel package has the normal uname and kernel-debug has the
EXTRARELEASE set to the flavor being built (either nothing, PAE, debug, or
PAEdebug).  So if you install and boot kernel-debug, your uname will look like:

3.2.3-2.fc16.i686.debug or 3.2.3-2.fc16.i686.PAEdebug

However, in rawhide (and f17 at the moment) we're building -rcX kernels and we
tend to leave the debug options always on.  That means the kernel package has
the options enabled and there is no kernel-debug package being built.  Once per
-rc, we flip the switch so we get both.

Tacking a .debug into EXTRARELEASE for the usual rawhide case might still be a
good idea.  I'll look into that tomorrow.

josh