Re: [PATCH 2/2] x86: speed cpu_up by quirking cpu_init_udelay

2015-05-09 Thread Borislav Petkov
On Sat, May 09, 2015 at 09:22:38AM +0200, Ingo Molnar wrote: > > * Len Brown wrote: > > > On Fri, May 8, 2015 at 4:32 AM, Borislav Petkov wrote: > > > > >> + pr_debug("cpu_init_udelay quirk to %d, was %d", new_udelay, > > >> init_udelay); > > > > > > Can we make this printk(KERN_DEBUG ple

Re: [PATCH 2/2] x86: speed cpu_up by quirking cpu_init_udelay

2015-05-09 Thread Ingo Molnar
(Resending my reply with more dyn-debug folks Cc:-ed) * Len Brown wrote: > On Fri, May 8, 2015 at 4:32 AM, Borislav Petkov wrote: > > >> + pr_debug("cpu_init_udelay quirk to %d, was %d", new_udelay, > >> init_udelay); > > > > Can we make this printk(KERN_DEBUG please? > > > > I'd like to

Re: [PATCH 2/2] x86: speed cpu_up by quirking cpu_init_udelay

2015-05-09 Thread Ingo Molnar
* Len Brown wrote: > On Fri, May 8, 2015 at 4:32 AM, Borislav Petkov wrote: > > >> + pr_debug("cpu_init_udelay quirk to %d, was %d", new_udelay, > >> init_udelay); > > > > Can we make this printk(KERN_DEBUG please? > > > > I'd like to be able to slap "debug" on the command line and not >

Re: [PATCH 2/2] x86: speed cpu_up by quirking cpu_init_udelay

2015-05-08 Thread Borislav Petkov
On Fri, May 08, 2015 at 02:15:42PM -0400, Len Brown wrote: > I agree with you. Further, you made me think about it, and while it > was helpful when I wrote the patch, I don't think any printk() is > needed upstream. Yeah, you're right. If a user did override it with cpu_init_udelay, it'll be in /

Re: [PATCH 2/2] x86: speed cpu_up by quirking cpu_init_udelay

2015-05-08 Thread Len Brown
On Fri, May 8, 2015 at 4:32 AM, Borislav Petkov wrote: >> + pr_debug("cpu_init_udelay quirk to %d, was %d", new_udelay, >> init_udelay); > > Can we make this printk(KERN_DEBUG please? > > I'd like to be able to slap "debug" on the command line and not > recompile the kernel. And no, dyndbg="

Re: [PATCH 2/2] x86: speed cpu_up by quirking cpu_init_udelay

2015-05-08 Thread Borislav Petkov
On Fri, May 08, 2015 at 02:37:55AM -0400, Len Brown wrote: > From: Len Brown > > Modern processor familes are on a white-list to remove > the costly cpu_init_udelay 1. Unknown processor families > get the traditional 10ms delay in cpu_up(). > > This seemed more efficient than forcing modern

Re: [PATCH 2/2] x86: speed cpu_up by quirking cpu_init_udelay

2015-05-08 Thread Borislav Petkov
On Fri, May 08, 2015 at 09:51:11AM +0200, Ingo Molnar wrote: > > +static const struct x86_cpu_id init_udelay_ids[] = { > > + { X86_VENDOR_INTEL, 0x6, X86_MODEL_ANY, X86_FEATURE_ANY, 0 }, > > + { X86_VENDOR_AMD, 0x16, X86_MODEL_ANY, X86_FEATURE_ANY, 0 }, > > + { X86_VENDOR_AMD, 0x15, X86_MODEL

Re: [PATCH 2/2] x86: speed cpu_up by quirking cpu_init_udelay

2015-05-08 Thread Ingo Molnar
* Len Brown wrote: > From: Len Brown > > Modern processor familes are on a white-list to remove > the costly cpu_init_udelay 1. Unknown processor families > get the traditional 10ms delay in cpu_up(). > > This seemed more efficient than forcing modern processors > to exhaustively search

[PATCH 2/2] x86: speed cpu_up by quirking cpu_init_udelay

2015-05-07 Thread Len Brown
From: Len Brown Modern processor familes are on a white-list to remove the costly cpu_init_udelay 1. Unknown processor families get the traditional 10ms delay in cpu_up(). This seemed more efficient than forcing modern processors to exhaustively search a black-list having all the old proces