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)
{
* Andi Kleen <[email protected]> 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
Ingo Molnar wrote:
> * Andi Kleen <[email protected]> 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
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.
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
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
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