Re: [DMESG] cpumask_t in action

Re: [DMESG] cpumask_t in action

[Matthew Wilcox]

On Wed, Nov 05, 2003 at 02:22:02PM -0800, Jesse Barnes wrote:
> I'm Cc'ing linux-ia64 because I think we have a lot of boot messages to
> cleanup in arch/ia64...

I agree.  I've booted on 16 way machines and been annoyed by the kernel
messages.  Did you set the dmesg buffer size to 128k or did you capture
the boot messages with a serial card?

The arch/ia64 code is not the only offender; ACPI is terribly verbose too.
I'm going to cc the acpi list too.  See comments below.

> ACPI: SRAT Processor (id[0x00] eid[0x00]) in proximity domain 0 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x00]) in proximity domain 0 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x02]) in proximity domain 1 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x02]) in proximity domain 1 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x04]) in proximity domain 2 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x04]) in proximity domain 2 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x06]) in proximity domain 3 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x06]) in proximity domain 3 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x08]) in proximity domain 4 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x08]) in proximity domain 4 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x0a]) in proximity domain 5 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x0a]) in proximity domain 5 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x0c]) in proximity domain 6 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x0c]) in proximity domain 6 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x0e]) in proximity domain 7 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x0e]) in proximity domain 7 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x10]) in proximity domain 8 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x10]) in proximity domain 8 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x12]) in proximity domain 9 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x12]) in proximity domain 9 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x14]) in proximity domain 10 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x14]) in proximity domain 10 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x16]) in proximity domain 11 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x16]) in proximity domain 11 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x18]) in proximity domain 12 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x18]) in proximity domain 12 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x1a]) in proximity domain 13 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x1a]) in proximity domain 13 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x1c]) in proximity domain 14 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x1c]) in proximity domain 14 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x1e]) in proximity domain 15 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x1e]) in proximity domain 15 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x20]) in proximity domain 16 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x20]) in proximity domain 16 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x22]) in proximity domain 17 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x22]) in proximity domain 17 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x24]) in proximity domain 18 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x24]) in proximity domain 18 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x26]) in proximity domain 19 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x26]) in proximity domain 19 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x28]) in proximity domain 20 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x28]) in proximity domain 20 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x2a]) in proximity domain 21 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x2a]) in proximity domain 21 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x2c]) in proximity domain 22 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x2c]) in proximity domain 22 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x2e]) in proximity domain 23 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x2e]) in proximity domain 23 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x30]) in proximity domain 24 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x30]) in proximity domain 24 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x32]) in proximity domain 25 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x32]) in proximity domain 25 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x34]) in proximity domain 26 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x34]) in proximity domain 26 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x36]) in proximity domain 27 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x36]) in proximity domain 27 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x38]) in proximity domain 28 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x38]) in proximity domain 28 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x3a]) in proximity domain 29 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x3a]) in proximity domain 29 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x3c]) in proximity domain 30 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x3c]) in proximity domain 30 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x3e]) in proximity domain 31 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x3e]) in proximity domain 31 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x40]) in proximity domain 32 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x40]) in proximity domain 32 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x42]) in proximity domain 33 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x42]) in proximity domain 33 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x44]) in proximity domain 34 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x44]) in proximity domain 34 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x46]) in proximity domain 35 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x46]) in proximity domain 35 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x48]) in proximity domain 36 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x48]) in proximity domain 36 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x4a]) in proximity domain 37 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x4a]) in proximity domain 37 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x4c]) in proximity domain 38 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x4c]) in proximity domain 38 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x4e]) in proximity domain 39 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x4e]) in proximity domain 39 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x50]) in proximity domain 40 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x50]) in proximity domain 40 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x52]) in proximity domain 41 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x52]) in proximity domain 41 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x54]) in proximity domain 42 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x54]) in proximity domain 42 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x56]) in proximity domain 43 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x56]) in proximity domain 43 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x58]) in proximity domain 44 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x58]) in proximity domain 44 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x5a]) in proximity domain 45 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x5a]) in proximity domain 45 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x5c]) in proximity domain 46 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x5c]) in proximity domain 46 enabled
> ACPI: SRAT Processor (id[0x00] eid[0x5e]) in proximity domain 47 enabled
> ACPI: SRAT Processor (id[0x20] eid[0x5e]) in proximity domain 47 enabled

... for example ;-)  96 lines which honestly tell me nothing.

> ACPI: SRAT Memory (0x0000003000000000 length 0x0000001000000000 type 0x1) in proximity domain 0 enabled
> ACPI: SRAT Memory (0x000000b000000000 length 0x0000001000000000 type 0x1) in proximity domain 1 enabled
[ snip 44 lines ]
> ACPI: SRAT Memory (0x0000173000000000 length 0x0000001000000000 type 0x1) in proximity domain 46 enabled
> ACPI: SRAT Memory (0x000017b000000000 length 0x0000001000000000 type 0x1) in proximity domain 47 enabled

... and again.

> CPU 0: 61 virtual and 50 physical address bits
> ACPI: Local APIC address 0xc0000000fee00000
> ACPI: LSAPIC (acpi_id[0x00] lsapic_id[0x00] lsapic_eid[0x00] enabled)
> CPU 0 (0x0000) enabled (BSP)
> ACPI: LSAPIC (acpi_id[0x01] lsapic_id[0x20] lsapic_eid[0x00] enabled)
> CPU 1 (0x2000) enabled
> ACPI: LSAPIC (acpi_id[0x02] lsapic_id[0x00] lsapic_eid[0x02] enabled)
> CPU 2 (0x0002) enabled
> ACPI: LSAPIC (acpi_id[0x03] lsapic_id[0x20] lsapic_eid[0x02] enabled)
> CPU 3 (0x2002) enabled
[ snip 180 lines ]
> ACPI: LSAPIC (acpi_id[0x5e] lsapic_id[0x00] lsapic_eid[0x5e] enabled)
> CPU 94 (0x005e) enabled
> ACPI: LSAPIC (acpi_id[0x5f] lsapic_id[0x20] lsapic_eid[0x5e] enabled)
> CPU 95 (0x205e) enabled

The information here, such as it is seems to be a duplicate of the SRAT
information above.

> Boot processor id 0x0/0x0
> task migration cache decay timeout: 10 msecs.
> Starting migration thread for cpu 0
> Bringing up 1
> Processor 8192/1 is spinning up...
> CPU 1: 61 virtual and 50 physical address bits
> CPU 1: nasid 0, slice 2, cnode 0
> CPU 1: base freq=200.000MHz, ITC ratio=15/2, ITC freq=1500.000MHz+/--1ppm
> Calibrating delay loop... 2232.84 BogoMIPS
> CPU1: CPU has booted.
> Processor 1 has spun up...
> CPU 1 IS NOW UP!
> Starting migration thread for cpu 1
> Bringing up 2
> Processor 2/2 is spinning up...
> CPU 2: 61 virtual and 50 physical address bits
> CPU 2: nasid 2, slice 0, cnode 1
> CPU 2: base freq=200.000MHz, ITC ratio=15/2, ITC freq=1500.000MHz+/--1ppm
> Calibrating delay loop... 2241.08 BogoMIPS
> CPU2: CPU has booted.
> Processor 2 has spun up...
> CPU 2 IS NOW UP!
> Starting migration thread for cpu 2

There's a number of things here that annoy me.  One is the stupid
"Processor 8192/1 is spinning up".  I would expect "Processor 2/96
is spinning up", but why have this line at all?  I'd also like to see
"Bringing up 3", "Processor 1 has spun up..." and "CPU 1 IS NOW UP!" go
away.  That'd cut us down to:

> CPU 3: 61 virtual and 50 physical address bits
> CPU 3: nasid 2, slice 2, cnode 1
> CPU 3: base freq=200.000MHz, ITC ratio=15/2, ITC freq=1500.000MHz+/--1ppm
> Calibrating delay loop... 2241.08 BogoMIPS
> CPU3: CPU has booted.
> Starting migration thread for cpu 3

A 40% reduction in per-cpu verbosity ;-)

[920 lines deleted]
> CPUS done 128
> Total of 96 processors activated (213739.60 BogoMIPS).
> NET: Registered protocol family 16
[96 lines which aren't too dissimilar to my K6 box deleted ;-)

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Re: [DMESG] cpumask_t in action

[Jesse Barnes]

On Thu, Nov 06, 2003 at 04:51:59PM +0000, Matthew Wilcox wrote:
> The arch/ia64 code is not the only offender; ACPI is terribly verbose too.
> I'm going to cc the acpi list too.  See comments below.
> 
> > ACPI: SRAT Processor (id[0x00] eid[0x00]) in proximity domain 0 enabled
[snip[
> > ACPI: SRAT Processor (id[0x20] eid[0x5e]) in proximity domain 47 enabled
> 
> ... for example ;-)  96 lines which honestly tell me nothing.
> 
> > ACPI: SRAT Memory (0x0000003000000000 length 0x0000001000000000 type 0x1) in proximity domain 0 enabled
> > ACPI: SRAT Memory (0x000000b000000000 length 0x0000001000000000 type 0x1) in proximity domain 1 enabled
> [ snip 44 lines ]
> > ACPI: SRAT Memory (0x0000173000000000 length 0x0000001000000000 type 0x1) in proximity domain 46 enabled
> > ACPI: SRAT Memory (0x000017b000000000 length 0x0000001000000000 type 0x1) in proximity domain 47 enabled

Here's one for those two.

Jesse

===== drivers/acpi/numa.c 1.5 vs edited =====
--- 1.5/drivers/acpi/numa.c	Tue Feb 18 12:56:05 2003
+++ edited/drivers/acpi/numa.c	Thu Nov  6 09:18:50 2003
@@ -31,6 +31,13 @@
 #include <linux/acpi.h>
 #include <acpi/acpi_bus.h>
 
+#undef ACPI_NUMA_DEBUG
+#ifdef ACPI_NUMA_DEBUG
+#define Dprintk(x...) printk(x)
+#else
+#define Dprintk(x...)
+#endif
+
 extern int __init acpi_table_parse_madt_family (enum acpi_table_id id, unsigned long madt_size, int entry_id, acpi_madt_entry_handler handler);
 
 void __init
@@ -46,7 +53,7 @@
 	{
 		struct acpi_table_processor_affinity *p =
 			(struct acpi_table_processor_affinity*) header;
-		printk(KERN_INFO PREFIX "SRAT Processor (id[0x%02x] eid[0x%02x]) in proximity domain %d %s\n",
+		Dprintk(KERN_INFO PREFIX "SRAT Processor (id[0x%02x] eid[0x%02x]) in proximity domain %d %s\n",
 		       p->apic_id, p->lsapic_eid, p->proximity_domain,
 		       p->flags.enabled?"enabled":"disabled");
 	}
@@ -56,7 +63,7 @@
 	{
 		struct acpi_table_memory_affinity *p =
 			(struct acpi_table_memory_affinity*) header;
-		printk(KERN_INFO PREFIX "SRAT Memory (0x%08x%08x length 0x%08x%08x type 0x%x) in proximity domain %d %s%s\n",
+		Dprintk(KERN_INFO PREFIX "SRAT Memory (0x%08x%08x length 0x%08x%08x type 0x%x) in proximity domain %d %s%s\n",
 		       p->base_addr_hi, p->base_addr_lo, p->length_hi, p->length_lo,
 		       p->memory_type, p->proximity_domain,
 		       p->flags.enabled ? "enabled" : "disabled",

Re: [DMESG] cpumask_t in action

[Jesse Barnes]

On Thu, Nov 06, 2003 at 04:51:59PM +0000, Matthew Wilcox wrote:
> The arch/ia64 code is not the only offender; ACPI is terribly verbose too.
> I'm going to cc the acpi list too.  See comments below.
> 
> ... and again.
> 
> > CPU 0: 61 virtual and 50 physical address bits
> > ACPI: Local APIC address 0xc0000000fee00000
> > ACPI: LSAPIC (acpi_id[0x00] lsapic_id[0x00] lsapic_eid[0x00] enabled)
> > CPU 0 (0x0000) enabled (BSP)
> > ACPI: LSAPIC (acpi_id[0x01] lsapic_id[0x20] lsapic_eid[0x00] enabled)
> > CPU 1 (0x2000) enabled
> > ACPI: LSAPIC (acpi_id[0x02] lsapic_id[0x00] lsapic_eid[0x02] enabled)
> > CPU 2 (0x0002) enabled
> > ACPI: LSAPIC (acpi_id[0x03] lsapic_id[0x20] lsapic_eid[0x02] enabled)
> > CPU 3 (0x2002) enabled
> [ snip 180 lines ]
> > ACPI: LSAPIC (acpi_id[0x5e] lsapic_id[0x00] lsapic_eid[0x5e] enabled)
> > CPU 94 (0x005e) enabled
> > ACPI: LSAPIC (acpi_id[0x5f] lsapic_id[0x20] lsapic_eid[0x5e] enabled)
> > CPU 95 (0x205e) enabled

And here's a patch to quiet this stuff.

Jesse

===== drivers/acpi/tables.c 1.16 vs edited =====
--- 1.16/drivers/acpi/tables.c	Thu Sep 18 16:22:09 2003
+++ edited/drivers/acpi/tables.c	Thu Nov  6 09:22:35 2003
@@ -35,6 +35,13 @@
 #include <linux/acpi.h>
 #include <linux/bootmem.h>
 
+#undef ACPI_TABLES_DEBUG
+#ifdef ACPI_TABLES_DEBUG
+#define Dprintk(x...) printk(x)
+#else
+#define Dprintk(x...)
+#endif
+
 #define PREFIX			"ACPI: "
 
 #define ACPI_MAX_TABLES		256
@@ -118,7 +125,7 @@
 	{
 		struct acpi_table_lapic *p =
 			(struct acpi_table_lapic*) header;
-		printk(KERN_INFO PREFIX "LAPIC (acpi_id[0x%02x] lapic_id[0x%02x] %s)\n",
+		Dprintk(KERN_INFO PREFIX "LAPIC (acpi_id[0x%02x] lapic_id[0x%02x] %s)\n",
 			p->acpi_id, p->id, p->flags.enabled?"enabled":"disabled");
 	}
 		break;
@@ -127,7 +134,7 @@
 	{
 		struct acpi_table_ioapic *p =
 			(struct acpi_table_ioapic*) header;
-		printk(KERN_INFO PREFIX "IOAPIC (id[0x%02x] address[0x%08x] global_irq_base[0x%x])\n",
+		Dprintk(KERN_INFO PREFIX "IOAPIC (id[0x%02x] address[0x%08x] global_irq_base[0x%x])\n",
 			p->id, p->address, p->global_irq_base);
 	}
 		break;
@@ -136,7 +143,7 @@
 	{
 		struct acpi_table_int_src_ovr *p =
 			(struct acpi_table_int_src_ovr*) header;
-		printk(KERN_INFO PREFIX "INT_SRC_OVR (bus[%d] irq[0x%x] global_irq[0x%x] polarity[0x%x] trigger[0x%x])\n",
+		Dprintk(KERN_INFO PREFIX "INT_SRC_OVR (bus[%d] irq[0x%x] global_irq[0x%x] polarity[0x%x] trigger[0x%x])\n",
 			p->bus, p->bus_irq, p->global_irq, p->flags.polarity, p->flags.trigger);
 	}
 		break;
@@ -145,7 +152,7 @@
 	{
 		struct acpi_table_nmi_src *p =
 			(struct acpi_table_nmi_src*) header;
-		printk(KERN_INFO PREFIX "NMI_SRC (polarity[0x%x] trigger[0x%x] global_irq[0x%x])\n",
+		Dprintk(KERN_INFO PREFIX "NMI_SRC (polarity[0x%x] trigger[0x%x] global_irq[0x%x])\n",
 			p->flags.polarity, p->flags.trigger, p->global_irq);
 	}
 		break;
@@ -154,7 +161,7 @@
 	{
 		struct acpi_table_lapic_nmi *p =
 			(struct acpi_table_lapic_nmi*) header;
-		printk(KERN_INFO PREFIX "LAPIC_NMI (acpi_id[0x%02x] polarity[0x%x] trigger[0x%x] lint[0x%x])\n",
+		Dprintk(KERN_INFO PREFIX "LAPIC_NMI (acpi_id[0x%02x] polarity[0x%x] trigger[0x%x] lint[0x%x])\n",
 			p->acpi_id, p->flags.polarity, p->flags.trigger, p->lint);
 	}
 		break;
@@ -163,7 +170,7 @@
 	{
 		struct acpi_table_lapic_addr_ovr *p =
 			(struct acpi_table_lapic_addr_ovr*) header;
-		printk(KERN_INFO PREFIX "LAPIC_ADDR_OVR (address[%p])\n",
+		Dprintk(KERN_INFO PREFIX "LAPIC_ADDR_OVR (address[%p])\n",
 			(void *) (unsigned long) p->address);
 	}
 		break;
@@ -172,7 +179,7 @@
 	{
 		struct acpi_table_iosapic *p =
 			(struct acpi_table_iosapic*) header;
-		printk(KERN_INFO PREFIX "IOSAPIC (id[0x%x] global_irq_base[0x%x] address[%p])\n",
+		Dprintk(KERN_INFO PREFIX "IOSAPIC (id[0x%x] global_irq_base[0x%x] address[%p])\n",
 			p->id, p->global_irq_base, (void *) (unsigned long) p->address);
 	}
 		break;
@@ -181,7 +188,7 @@
 	{
 		struct acpi_table_lsapic *p =
 			(struct acpi_table_lsapic*) header;
-		printk(KERN_INFO PREFIX "LSAPIC (acpi_id[0x%02x] lsapic_id[0x%02x] lsapic_eid[0x%02x] %s)\n",
+		Dprintk(KERN_INFO PREFIX "LSAPIC (acpi_id[0x%02x] lsapic_id[0x%02x] lsapic_eid[0x%02x] %s)\n",
 			p->acpi_id, p->id, p->eid, p->flags.enabled?"enabled":"disabled");
 	}
 		break;
@@ -190,7 +197,7 @@
 	{
 		struct acpi_table_plat_int_src *p =
 			(struct acpi_table_plat_int_src*) header;
-		printk(KERN_INFO PREFIX "PLAT_INT_SRC (polarity[0x%x] trigger[0x%x] type[0x%x] id[0x%04x] eid[0x%x] iosapic_vector[0x%x] global_irq[0x%x]\n",
+		Dprintk(KERN_INFO PREFIX "PLAT_INT_SRC (polarity[0x%x] trigger[0x%x] type[0x%x] id[0x%04x] eid[0x%x] iosapic_vector[0x%x] global_irq[0x%x]\n",
 			p->flags.polarity, p->flags.trigger, p->type, p->id, p->eid, p->iosapic_vector, p->global_irq);
 	}
 		break;
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [DMESG] cpumask_t in action

[Jes Sorensen]

>>>>> "Matthew" == Matthew Wilcox <willy-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org> writes:

Matthew> On Wed, Nov 05, 2003 at 02:22:02PM -0800, Jesse Barnes wrote:

Matthew> There's a number of things here that annoy me.  One is the
Matthew> stupid "Processor 8192/1 is spinning up".  I would expect
Matthew> "Processor 2/96 is spinning up", but why have this line at
Matthew> all?  I'd also like to see "Bringing up 3", "Processor 1 has
Matthew> spun up..." and "CPU 1 IS NOW UP!" go away.  That'd cut us
Matthew> down to:

>> CPU 3: 61 virtual and 50 physical address bits CPU 3: nasid 2,
>> slice 2, cnode 1 CPU 3: base freq=200.000MHz, ITC ratio=15/2, ITC
>> freq=1500.000MHz+/--1ppm Calibrating delay loop... 2241.08 BogoMIPS
>> CPU3: CPU has booted.  Starting migration thread for cpu 3

Matthew> A 40% reduction in per-cpu verbosity ;-)

Why not turn it the other way and just report the success of booted
CPUs and more detailed results for the CPUs that failed? I know there
are cases where you want the debug info in case of tracking kernel
bugs, but one could stick a compile time debug flag into the code for
that case, 960 - 40% = 576 lines of guff is still way too much IMHO,
especially over a serial console.

Cheers,
Jes


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/

Re: [DMESG] cpumask_t in action

[Sylvain Jeaugey]

On Thu, 6 Nov 2003, Matthew Wilcox wrote:

> > ACPI: SRAT Processor (id[0x00] eid[0x00]) in proximity domain 0 enabled
> > ACPI: SRAT Processor (id[0x20] eid[0x00]) in proximity domain 0 enabled
[...]
> > ACPI: SRAT Processor (id[0x00] eid[0x5e]) in proximity domain 47 enabled
> > ACPI: SRAT Processor (id[0x20] eid[0x5e]) in proximity domain 47 enabled
> 
> ... for example ;-)  96 lines which honestly tell me nothing.
> 
> > ACPI: SRAT Memory (0x0000003000000000 length 0x0000001000000000 type 0x1) in proximity domain 0 enabled
> > ACPI: SRAT Memory (0x000000b000000000 length 0x0000001000000000 type 0x1) in proximity domain 1 enabled
> [ snip 44 lines ]
> > ACPI: SRAT Memory (0x0000173000000000 length 0x0000001000000000 type 0x1) in proximity domain 46 enabled
> > ACPI: SRAT Memory (0x000017b000000000 length 0x0000001000000000 type 0x1) in proximity domain 47 enabled
> 
> ... and again.
> 
These lines show you the numa topology of your machine (in our case, we 
have 2 CPUS per domain, and a memory area).
This is quite a big piece of information about hardware. Even if it is 
quite long, I think it should be part of the ACPI information.

Sylvain

-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [DMESG] cpumask_t in action

[Matthew Wilcox]

On Fri, Nov 07, 2003 at 09:13:11AM +0100, Sylvain Jeaugey wrote:
> On Thu, 6 Nov 2003, Matthew Wilcox wrote:
> These lines show you the numa topology of your machine (in our case, we 
> have 2 CPUS per domain, and a memory area).
> This is quite a big piece of information about hardware. Even if it is 
> quite long, I think it should be part of the ACPI information.

Yes, but do we need to know it at boot time, or should it be available
in some other way (eg /proc/acpi/srat or something).  I would argue
that is more useful than seeing it in dmesg.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk


-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/

Re: Re: [DMESG] cpumask_t in action

[Jesse Barnes]

On Fri, Nov 07, 2003 at 05:24:56PM +0000, Matthew Wilcox wrote:
> On Fri, Nov 07, 2003 at 09:13:11AM +0100, Sylvain Jeaugey wrote:
> > On Thu, 6 Nov 2003, Matthew Wilcox wrote:
> > These lines show you the numa topology of your machine (in our case, we 
> > have 2 CPUS per domain, and a memory area).
> > This is quite a big piece of information about hardware. Even if it is 
> > quite long, I think it should be part of the ACPI information.
> 
> Yes, but do we need to know it at boot time, or should it be available
> in some other way (eg /proc/acpi/srat or something).  I would argue
> that is more useful than seeing it in dmesg.

There's also /sys which contains information about which cpus are on
which nodes.

Jesse


-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/

Re: [DMESG] cpumask_t in action

[Jes Sorensen]

>>>>> "Sylvain" == Sylvain Jeaugey <sylvain.jeaugey@bull.net> writes:

Sylvain> These lines show you the numa topology of your machine (in
Sylvain> our case, we have 2 CPUS per domain, and a memory area).
Sylvain> This is quite a big piece of information about hardware. Even
Sylvain> if it is quite long, I think it should be part of the ACPI
Sylvain> information.

Hi Sylvian,

This information is much better exposed through sysfs (/sys) and Andi
Kleen's libnuma, which will also make it visible at runtime to
applications.

Cheers,
Jes