linux-kernel - Re: [PATCH 2/2] x86: Reduce verbosity of "PAT enabled" kernel message

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 24 Sep 2009 11:38:00 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Roland Dreier <rdreier@...co.com>
Cc:	Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Suresh Siddha <suresh.b.siddha@...el.com>,
	Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] x86: Reduce verbosity of "PAT enabled" kernel
	message


* Roland Dreier <rdreier@...co.com> wrote:

> By the way, there is further work to be done in this direction... 
> these were the easy ones (that save me 127 lines of dmesg :).

thanks Roland - i've applied them to tip:x86/urgent, for v2.6.32 merge.

Feel free to send more such patches, they are nice improvements.

> The philosophy should probably be things that we would want to see to 
> debug crashes at boot should go into the kernel log -- that makes it 
> easy for users to grab the output and send it on for debugging.  If we 
> can move other stuff somewhere that users can grab easily after boot, 
> then that's probably worth it.
> 
> I think the next things to look at are:
> 
> * secondary CPU booting:
> 
>      Calibrating delay using timer specific routine.. xxxx BogoMIPS (lpj=xxxx)
>      CPU: Physical Processor ID: 2
>      CPU: Processor Core ID: 0
>      CPU: L1 I cache: xxxx, L1 D cache: xxxx
>      CPU: L2 cache: xxxx
>      CPU: L3 cache: xxxx
>      CPU 1/0x40 -> Node 0
>      mce: CPU supports xxxx MCE banks
>      CPU1: Thermal monitoring enabled (TM1)
>      CPU 1 MCA banks ....
> 
>   where all 64 CPUs are exactly the same -- I guess checking for
>   non-homogenous systems might be kind of complicated but we really
>   shouldn't print all this for every CPU when they all match the boot
>   CPU precisely.

Agreed.

> 
> * scheduler domain stuff:
> 
>      CPU0 attaching sched-domain:
>       domain 0: span 0,32 level SIBLING
>        groups: 0 (cpu_power = xxxx) 32 (cpu_power = xxxx)
>        domain 1: span 0,4,8,12,16,20,24,28,32,36,40,44,48,52,56,60 level MC
>         groups: 0,32 (cpu_power = xxxx) 4,36 (cpu_power = xxxx) 8,40 (cpu_power = xxxx) 12,44 (cpu_power = xxxx) 16,48 (cpu_power = xxxx) 20,52 (cpu_power = xxxx) 24,56 (cpu_power = xxxx) 28,60 (cpu_power = xxxx)
>         domain 2: span 0-63 level CPU
>          groups: 0,4,8,12,16,20,24,28,32,36,40,44,48,52,56,60 (cpu_power = xxxx) 1,5,9,13,17,21,25,29,33,37,41,45,49,53,57,61 (cpu_power = xxxx) 2,6,10,14,18,22,26,30,34,38,42,46,50,54,58,62 (cpu_power = xxxx) 3,7,11,15,19,23,27,31,35,39,43,47,51,55,59,63 (cpu_power = xxxx)
> 
>   not sure what the best way to present this is but 64 copies of this
>   output do consume a lot of log buffer space!

Just turn it off after the first instance and give it a sched=debug boot 
parameter perhaps - that's enough.

> * misc stuff, where we get 64 copies of a single message, eg
> 
>      Switched to high resolution mode on CPU 0
> 
>      ACPI: Processor [CPU0] (supports 8 throttling states)
>      processor LNXCPU:01: registered as cooling_device1

Yeah. The switched-to message could be eliminated altogether.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/