[PATCH] Disable scheduler debugging

[PATCH] Disable scheduler debugging

[Andi Kleen]

The domain scheduler spews out a lot of information at boot up, but it looks
mostly redundant because it's just a transformation of what is in /proc/cpuinfo
anyways. Also it is well tested now. Disable it.

diff -u linux/kernel/sched.c-o linux/kernel/sched.c
--- linux/kernel/sched.c-o	2004-06-01 19:19:58.000000000 +0200
+++ linux/kernel/sched.c	2004-06-01 19:26:56.000000000 +0200
@@ -3641,7 +3641,7 @@
 #endif /* CONFIG_NUMA_SCHED */
 #endif /* ARCH_HAS_SCHED_DOMAIN */
 
-#define SCHED_DOMAIN_DEBUG
+#undef SCHED_DOMAIN_DEBUG
 #ifdef SCHED_DOMAIN_DEBUG
 void sched_domain_debug(void)
 {

Re: [PATCH] Disable scheduler debugging

[Ingo Molnar]

* Andi Kleen <ak@suse.de> wrote:

> The domain scheduler spews out a lot of information at boot up, but it
> looks mostly redundant because it's just a transformation of what is
> in /proc/cpuinfo anyways. Also it is well tested now. Disable it.

i'd rather keep it some more, there are still open issues and if there's
a boot failure or early crash it makes it easier for us to see the
actual domain setup. Also, the messages are KERN_DEBUG.

	Ingo

Re: [PATCH] Disable scheduler debugging

[Jeff Garzik]

Ingo Molnar wrote:
> * Andi Kleen <ak@suse.de> wrote:
> 
> 
>>The domain scheduler spews out a lot of information at boot up, but it
>>looks mostly redundant because it's just a transformation of what is
>>in /proc/cpuinfo anyways. Also it is well tested now. Disable it.
> 
> 
> i'd rather keep it some more, there are still open issues and if there's
> a boot failure or early crash it makes it easier for us to see the
> actual domain setup. Also, the messages are KERN_DEBUG.


Unfortunately there are just, flat-out, way too many kernel messages at 
boot-up.  Making them KERN_DEBUG doesn't solve the fact that SMP boxes 
often overflow the printk buffer before you boot up to a useful userland 
that can record the dmesg.

The IO-APIC code is a _major_ offender in this area, but the CPU code is 
right up there as well.

	Jeff

Re: [PATCH] Disable scheduler debugging

[Zwane Mwaikambo]

On Sun, 6 Jun 2004, Jeff Garzik wrote:

> Unfortunately there are just, flat-out, way too many kernel messages at
> boot-up.  Making them KERN_DEBUG doesn't solve the fact that SMP boxes
> often overflow the printk buffer before you boot up to a useful userland
> that can record the dmesg.
>
> The IO-APIC code is a _major_ offender in this area, but the CPU code is
> right up there as well.

How about the configurable log buffer size patch? I think Andrew still has
that amongst his wares.

Re: [PATCH] Disable scheduler debugging

[Randy.Dunlap]

On Sun, 06 Jun 2004 17:55:07 -0400 Jeff Garzik wrote:

| Zwane Mwaikambo wrote:
| > On Sun, 6 Jun 2004, Jeff Garzik wrote:
| > 
| > 
| >>Unfortunately there are just, flat-out, way too many kernel messages at
| >>boot-up.  Making them KERN_DEBUG doesn't solve the fact that SMP boxes
| >>often overflow the printk buffer before you boot up to a useful userland
| >>that can record the dmesg.
| >>
| >>The IO-APIC code is a _major_ offender in this area, but the CPU code is
| >>right up there as well.
| > 
| > 
| > How about the configurable log buffer size patch? I think Andrew still has
| > that amongst his wares.
| 
| It's in mainline.  That's no excuse for the voluminous logs, though... 
| I'm a "1-2 lines per module" type of person :)

It's mainline, both CONFIG and command-line settable.

I'm a "there's always some case where more info is needed"
type of person.  But it won't happen on the next boot....
especially if the log size is increased.  :(

--
~Randy

Re: [PATCH] Disable scheduler debugging

[Jeff Garzik]

Zwane Mwaikambo wrote:
> On Sun, 6 Jun 2004, Jeff Garzik wrote:
> 
> 
>>Unfortunately there are just, flat-out, way too many kernel messages at
>>boot-up.  Making them KERN_DEBUG doesn't solve the fact that SMP boxes
>>often overflow the printk buffer before you boot up to a useful userland
>>that can record the dmesg.
>>
>>The IO-APIC code is a _major_ offender in this area, but the CPU code is
>>right up there as well.
> 
> 
> How about the configurable log buffer size patch? I think Andrew still has
> that amongst his wares.

It's in mainline.  That's no excuse for the voluminous logs, though... 
I'm a "1-2 lines per module" type of person :)

	Jeff

Re: [PATCH] Disable scheduler debugging

[David Lang]

On Sun, 6 Jun 2004, Jeff Garzik wrote:

>
> Unfortunately there are just, flat-out, way too many kernel messages at 
> boot-up.  Making them KERN_DEBUG doesn't solve the fact that SMP boxes often 
> overflow the printk buffer before you boot up to a useful userland that can 
> record the dmesg.
>
> The IO-APIC code is a _major_ offender in this area, but the CPU code is 
> right up there as well.
>
neither of these are nearly as bad as the crypto code, it takes a HUGE 
kernel log to get any info from before that if you enable all the 
encryption modes.

David Lang


-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan