Re: [PATCH] x86, mce: short output of MCE banks ownership information

[Mike Travis]

I have a patch coming that summarizes the Booting processor msgs and
the Processor information messages:

The first increases the start count by a power of 2 so 4096 cpus
would only need 12 lines.

[   25.388280] Booting Processors 1-7,320-327, Nodes 0-0
[   26.064742] Booting Processors 8-15,328-335, Nodes 1-1
[   26.837006] Booting Processors 16-31,336-351, Nodes 2-3
[   28.440427] Booting Processors 32-63,352-383, Nodes 4-7
[   31.640450] Booting Processors 64-127,384-447, Nodes 8-15
[   38.041430] Booting Processors 128-255,448-575, Nodes 16-31
[   50.917504] Booting Processors 256-319,576-639, Nodes 32-63 

(the last line has a slight error in that actually only nodes 32-39
were starting.  Btw, the processor numbers are correct, according
to the Intel spec.)

and

[  103.860206] Summary Processor information for CPUS: 0-639
[  103.864032] Genuine Intel(R) CPU             0000 @ 2.13GHz stepping 04
[  103.873403] CPU: L1 I cache: 32K, L1 D cache: 32K
[  103.877885] CPU: L2 cache: 256K
[  103.880032] CPU: L3 cache: 24576K
[  103.884032] MIN 4266.68 BogoMIPS (lpj=8533378)
[  103.888032] MAX 4267.70 BogoMIPS (lpj=8535412)
[  103.896248] Total of 640 processors activated (2731043.30 BogoMIPS).

This summary looks for different cpu types, steppings and cache sizes.

                                                        
Hidetoshi Seto wrote:
> Roland Dreier wrote:
> > Seems OK, but I think it would be even more useful to find a way to
> > print fewer lines of output; with CPUs that will be released shortly, a
> > system with 64 or even 128 logical CPUs will not be will not be that
> > exotic, and producing 128 lines of kernel log output for debugging
> > information that is rarely used and where the same info can be expressed
> > in 2 or 3 lines is silly-looking (and very annoying on a 57600 bps
> > serial console!).
>
> Thanks for your review!
>
> I think we could some effort like this for other messages during
> CPU initialization.
>
> For example I googled a full dmesg of recent hardware:
>   http://www.gossamer-threads.com/lists/linux/kernel/1134265
> It shows that the lines like:
>    :
>   Booting processor 1 APIC 0x2 ip 0x6000
>   Initializing CPU#1 
>   Calibrating delay using timer specific routine.. 5344.67 BogoMIPS (lpj=2672337) 
>   CPU: Physical Processor ID: 0 
>   CPU: Processor Core ID: 1 
>   CPU: L1 I cache: 32K, L1 D cache: 32K 
>   CPU: L2 cache: 256K 
>   CPU: L3 cache: 8192K 
>   mce: CPU supports 9 MCE banks 
>   CPU1: Thermal monitoring enabled (TM1) 
>   CPU 1 MCA banks CMCI:2 CMCI:3 CMCI:5 SHD:6 SHD:8 
>   x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106 
>   CPU1: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stepping 04 
>   Skipping synchronization checks as TSC is reliable. 
>    :
> are that printed for every cpu.
>
> We already eliminated "mce: CPU supports X MCE banks" in this repeat
> and now going to compress "CPU X MCA banks ..." line.
>
> I suppose:
>   - Cache information can be compressed too, could be in one line.
>   - Usually model name (and also cache size) will be same on all cpu.
>
> I can understand that it is better to avoid printing same lines
> again and again.  But there are more redundant messages...
>
> Maybe there would be more desirable ways, but I think that
> "compress messages shorter to bear heavy repeating" will be
> a good way at this time.
>
>
> Thanks,
> H.Seto
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/