On Tue, Apr 21, 2015 at 11:07 PM, Ingo Molnar wrote:
>
> * Paul Gortmaker wrote:
>> Happened to notice a 2x "The the..." when I came across this in
>> linux-next today and was reading the help out of curiousity...
>
> Len, this commit isn't in a permanent Git tree yet, right? We want to
> do
On Tue, Apr 21, 2015 at 11:07 PM, Ingo Molnar mi...@kernel.org wrote:
* Paul Gortmaker paul.gortma...@windriver.com wrote:
Happened to notice a 2x The the... when I came across this in
linux-next today and was reading the help out of curiousity...
Len, this commit isn't in a permanent Git
* Paul Gortmaker wrote:
> On Sat, Apr 18, 2015 at 8:53 PM, Len Brown wrote:
> > From: Len Brown
> >
>
> [...]
>
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > index b7d31ca..d2a91da 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -884,6 +884,21 @@ config
* Paul Gortmaker paul.gortma...@windriver.com wrote:
On Sat, Apr 18, 2015 at 8:53 PM, Len Brown l...@kernel.org wrote:
From: Len Brown len.br...@intel.com
[...]
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index b7d31ca..d2a91da 100644
--- a/arch/x86/Kconfig
+++
On Sat, Apr 18, 2015 at 8:53 PM, Len Brown wrote:
> From: Len Brown
>
[...]
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index b7d31ca..d2a91da 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -884,6 +884,21 @@ config SCHED_MC
> making when dealing with
On Sat, Apr 18, 2015 at 8:53 PM, Len Brown l...@kernel.org wrote:
From: Len Brown len.br...@intel.com
[...]
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index b7d31ca..d2a91da 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -884,6 +884,21 @@ config SCHED_MC
making
* Brown, Len wrote:
> > What's the cutoff for 'modern hardware' - which CPUs stopped requiring
> > the delay?
>
> This is the topic of ongoing research, and I'm not ready to send
> the patch setting a new default until I've heard back from a few more HW
> people.
>
> Every system I've tested
> What's the cutoff for 'modern hardware' - which CPUs stopped requiring
> the delay?
This is the topic of ongoing research, and I'm not ready to send
the patch setting a new default until I've heard back from a few more HW people.
Every system I've tested appears to work with delay 0.
Were I to
* Len Brown wrote:
> +config X86_INIT_MDELAY
> + int "Milliseconds to wait to de-assert INIT upon CPU startup" if SMP
> + range 0 10
> + default "10"
> + ---help---
> + This allows you to specify how long the BSP will delay
> + between asserting INIT and de-asserting
What's the cutoff for 'modern hardware' - which CPUs stopped requiring
the delay?
This is the topic of ongoing research, and I'm not ready to send
the patch setting a new default until I've heard back from a few more HW people.
Every system I've tested appears to work with delay 0.
Were I to
* Len Brown l...@kernel.org wrote:
+config X86_INIT_MDELAY
+ int Milliseconds to wait to de-assert INIT upon CPU startup if SMP
+ range 0 10
+ default 10
+ ---help---
+ This allows you to specify how long the BSP will delay
+ between asserting INIT and
* Brown, Len len.br...@intel.com wrote:
What's the cutoff for 'modern hardware' - which CPUs stopped requiring
the delay?
This is the topic of ongoing research, and I'm not ready to send
the patch setting a new default until I've heard back from a few more HW
people.
Every system
From: Len Brown
Default behavior unchanged.
cpu_up() has a hard-coded mdelay(10). Change that to a variable,
with default CONFIG_X86_INIT_MDELAY
and a boot-time override, "cpu_init_mdelay=N"
This patch adds mechanism without changing default policy.
Default policy will be changed in a
From: Len Brown len.br...@intel.com
Default behavior unchanged.
cpu_up() has a hard-coded mdelay(10). Change that to a variable,
with default CONFIG_X86_INIT_MDELAY
and a boot-time override, cpu_init_mdelay=N
This patch adds mechanism without changing default policy.
Default policy will be
14 matches
Mail list logo
