Re: [PATCH 0/1] speeding up cpu_up()
On Mon, May 04, 2015 at 05:45:17PM -0500, Aravind Gopalakrishnan wrote: > Tested a delay of 0 on Fam10h and Fam15h Model 30h-3fh and both work fine. Cool, thanks for testing. > Feedback from asking internally about this is that we should be OK to move > to a no-delay default from K8 onwards. Also cool :-) @Len: So everything with X86_VENDOR_AMD and c->x86 >= 0xf should be fine. Thanks. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/1] speeding up cpu_up()
On Mon, May 04, 2015 at 05:45:17PM -0500, Aravind Gopalakrishnan wrote: Tested a delay of 0 on Fam10h and Fam15h Model 30h-3fh and both work fine. Cool, thanks for testing. Feedback from asking internally about this is that we should be OK to move to a no-delay default from K8 onwards. Also cool :-) @Len: So everything with X86_VENDOR_AMD and c-x86 = 0xf should be fine. Thanks. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/1] speeding up cpu_up()
On 5/3/2015 11:13 AM, Aravind Gopalakrishnan wrote: On 5/1/15 7:42 PM, Aravind Gopalakrishnan wrote: On 5/1/15 5:47 PM, Borislav Petkov wrote: Aravind and I could probably test on a couple of AMD boxes to narrow down. @Aravind, see here: https://lkml.kernel.org/r/87d69aab88c14d65ae1e7be55050d1b689b59b4b.1429402494.git.len.br...@intel.com You could ask around whether a timeout is needed between the assertion and deassertion of INIT done by the BSP when booting other cores. Sure, I'll ask around and try mdelay(0) on some systems as well. I can gather Fam15h, Fam16h but don't have K8's or older. Will let you know how it goes. Update: Fam15h Model00h-0fh, Fam15hModel60h and Fam16h Model 00h-0fh processors boot fine with mdelay(0) and BSP brings up all secondary cpus correctly. I don't have Fam15hModel30h system currently up, but I'll try that too tomorrow. I am yet to get feedback from HW folks regarding this though. Tested a delay of 0 on Fam10h and Fam15h Model 30h-3fh and both work fine. Feedback from asking internally about this is that we should be OK to move to a no-delay default from K8 onwards. Thanks, -Aravind. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/1] speeding up cpu_up()
On 5/3/2015 11:13 AM, Aravind Gopalakrishnan wrote: On 5/1/15 7:42 PM, Aravind Gopalakrishnan wrote: On 5/1/15 5:47 PM, Borislav Petkov wrote: Aravind and I could probably test on a couple of AMD boxes to narrow down. @Aravind, see here: https://lkml.kernel.org/r/87d69aab88c14d65ae1e7be55050d1b689b59b4b.1429402494.git.len.br...@intel.com You could ask around whether a timeout is needed between the assertion and deassertion of INIT done by the BSP when booting other cores. Sure, I'll ask around and try mdelay(0) on some systems as well. I can gather Fam15h, Fam16h but don't have K8's or older. Will let you know how it goes. Update: Fam15h Model00h-0fh, Fam15hModel60h and Fam16h Model 00h-0fh processors boot fine with mdelay(0) and BSP brings up all secondary cpus correctly. I don't have Fam15hModel30h system currently up, but I'll try that too tomorrow. I am yet to get feedback from HW folks regarding this though. Tested a delay of 0 on Fam10h and Fam15h Model 30h-3fh and both work fine. Feedback from asking internally about this is that we should be OK to move to a no-delay default from K8 onwards. Thanks, -Aravind. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/1] speeding up cpu_up()
On 5/1/15 7:42 PM, Aravind Gopalakrishnan wrote: On 5/1/15 5:47 PM, Borislav Petkov wrote: On Fri, May 01, 2015 at 02:42:39PM -0700, Len Brown wrote: On Mon, Apr 20, 2015 at 12:15 AM, Ingo Molnar wrote: So instead of playing games with an ancient delay, I'd suggest we install the 10 msec INIT assertion wait as a platform quirk instead, and activate it for all CPUs/systems that we think might need it, with a sufficiently robust and future-proof quirk cutoff condition. New systems won't have the quirk active and thus won't have to have this delay configurable either. Okay, at this time, I think the quirk would apply to: 1. Intel family 5 (original pentium) -- some may actually need the quirk 2. Intel family F (pentium4) -- mostly b/c I don't want to bother finding/testing p4 3. All AMD (happy to narrow down, if somebody can speak for AMD) Aravind and I could probably test on a couple of AMD boxes to narrow down. @Aravind, see here: https://lkml.kernel.org/r/87d69aab88c14d65ae1e7be55050d1b689b59b4b.1429402494.git.len.br...@intel.com You could ask around whether a timeout is needed between the assertion and deassertion of INIT done by the BSP when booting other cores. Sure, I'll ask around and try mdelay(0) on some systems as well. I can gather Fam15h, Fam16h but don't have K8's or older. Will let you know how it goes. Update: Fam15h Model00h-0fh, Fam15hModel60h and Fam16h Model 00h-0fh processors boot fine with mdelay(0) and BSP brings up all secondary cpus correctly. I don't have Fam15hModel30h system currently up, but I'll try that too tomorrow. I am yet to get feedback from HW folks regarding this though. Thanks, -Aravind. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/1] speeding up cpu_up()
On 5/1/15 7:42 PM, Aravind Gopalakrishnan wrote: On 5/1/15 5:47 PM, Borislav Petkov wrote: On Fri, May 01, 2015 at 02:42:39PM -0700, Len Brown wrote: On Mon, Apr 20, 2015 at 12:15 AM, Ingo Molnar mi...@kernel.org wrote: So instead of playing games with an ancient delay, I'd suggest we install the 10 msec INIT assertion wait as a platform quirk instead, and activate it for all CPUs/systems that we think might need it, with a sufficiently robust and future-proof quirk cutoff condition. New systems won't have the quirk active and thus won't have to have this delay configurable either. Okay, at this time, I think the quirk would apply to: 1. Intel family 5 (original pentium) -- some may actually need the quirk 2. Intel family F (pentium4) -- mostly b/c I don't want to bother finding/testing p4 3. All AMD (happy to narrow down, if somebody can speak for AMD) Aravind and I could probably test on a couple of AMD boxes to narrow down. @Aravind, see here: https://lkml.kernel.org/r/87d69aab88c14d65ae1e7be55050d1b689b59b4b.1429402494.git.len.br...@intel.com You could ask around whether a timeout is needed between the assertion and deassertion of INIT done by the BSP when booting other cores. Sure, I'll ask around and try mdelay(0) on some systems as well. I can gather Fam15h, Fam16h but don't have K8's or older. Will let you know how it goes. Update: Fam15h Model00h-0fh, Fam15hModel60h and Fam16h Model 00h-0fh processors boot fine with mdelay(0) and BSP brings up all secondary cpus correctly. I don't have Fam15hModel30h system currently up, but I'll try that too tomorrow. I am yet to get feedback from HW folks regarding this though. Thanks, -Aravind. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/1] speeding up cpu_up()
On 5/1/15 5:47 PM, Borislav Petkov wrote: On Fri, May 01, 2015 at 02:42:39PM -0700, Len Brown wrote: On Mon, Apr 20, 2015 at 12:15 AM, Ingo Molnar wrote: So instead of playing games with an ancient delay, I'd suggest we install the 10 msec INIT assertion wait as a platform quirk instead, and activate it for all CPUs/systems that we think might need it, with a sufficiently robust and future-proof quirk cutoff condition. New systems won't have the quirk active and thus won't have to have this delay configurable either. Okay, at this time, I think the quirk would apply to: 1. Intel family 5 (original pentium) -- some may actually need the quirk 2. Intel family F (pentium4) -- mostly b/c I don't want to bother finding/testing p4 3. All AMD (happy to narrow down, if somebody can speak for AMD) Aravind and I could probably test on a couple of AMD boxes to narrow down. @Aravind, see here: https://lkml.kernel.org/r/87d69aab88c14d65ae1e7be55050d1b689b59b4b.1429402494.git.len.br...@intel.com You could ask around whether a timeout is needed between the assertion and deassertion of INIT done by the BSP when booting other cores. Sure, I'll ask around and try mdelay(0) on some systems as well. I can gather Fam15h, Fam16h but don't have K8's or older. Will let you know how it goes. -Aravind. If not, we probably should convert, at least modern AMD machines, to the no-delay default. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/1] speeding up cpu_up()
On Fri, May 01, 2015 at 02:42:39PM -0700, Len Brown wrote: > On Mon, Apr 20, 2015 at 12:15 AM, Ingo Molnar wrote: > > > So instead of playing games with an ancient delay, I'd suggest we > > install the 10 msec INIT assertion wait as a platform quirk instead, > > and activate it for all CPUs/systems that we think might need it, with > > a sufficiently robust and future-proof quirk cutoff condition. > > > > New systems won't have the quirk active and thus won't have to have > > this delay configurable either. > > Okay, at this time, I think the quirk would apply to: > > 1. Intel family 5 (original pentium) -- some may actually need the quirk > 2. Intel family F (pentium4) -- mostly b/c I don't want to bother > finding/testing p4 > 3. All AMD (happy to narrow down, if somebody can speak for AMD) Aravind and I could probably test on a couple of AMD boxes to narrow down. @Aravind, see here: https://lkml.kernel.org/r/87d69aab88c14d65ae1e7be55050d1b689b59b4b.1429402494.git.len.br...@intel.com You could ask around whether a timeout is needed between the assertion and deassertion of INIT done by the BSP when booting other cores. If not, we probably should convert, at least modern AMD machines, to the no-delay default. > I'd keep the cmdline override, in case we break something, > or somebody wants to optimize/test. (Though I'll update units to > usec, rather than msec., > so we can go below 1ms without going to 0) > I don't think we need the config option, just a #define to document the quirk. > > What do you think? > > Len Brown, Intel Open Source Technology Center > -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/1] speeding up cpu_up()
On Mon, Apr 20, 2015 at 12:15 AM, Ingo Molnar wrote: > So instead of playing games with an ancient delay, I'd suggest we > install the 10 msec INIT assertion wait as a platform quirk instead, > and activate it for all CPUs/systems that we think might need it, with > a sufficiently robust and future-proof quirk cutoff condition. > > New systems won't have the quirk active and thus won't have to have > this delay configurable either. Okay, at this time, I think the quirk would apply to: 1. Intel family 5 (original pentium) -- some may actually need the quirk 2. Intel family F (pentium4) -- mostly b/c I don't want to bother finding/testing p4 3. All AMD (happy to narrow down, if somebody can speak for AMD) I'd keep the cmdline override, in case we break something, or somebody wants to optimize/test. (Though I'll update units to usec, rather than msec., so we can go below 1ms without going to 0) I don't think we need the config option, just a #define to document the quirk. What do you think? Len Brown, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/1] speeding up cpu_up()
On 5/1/15 5:47 PM, Borislav Petkov wrote: On Fri, May 01, 2015 at 02:42:39PM -0700, Len Brown wrote: On Mon, Apr 20, 2015 at 12:15 AM, Ingo Molnar mi...@kernel.org wrote: So instead of playing games with an ancient delay, I'd suggest we install the 10 msec INIT assertion wait as a platform quirk instead, and activate it for all CPUs/systems that we think might need it, with a sufficiently robust and future-proof quirk cutoff condition. New systems won't have the quirk active and thus won't have to have this delay configurable either. Okay, at this time, I think the quirk would apply to: 1. Intel family 5 (original pentium) -- some may actually need the quirk 2. Intel family F (pentium4) -- mostly b/c I don't want to bother finding/testing p4 3. All AMD (happy to narrow down, if somebody can speak for AMD) Aravind and I could probably test on a couple of AMD boxes to narrow down. @Aravind, see here: https://lkml.kernel.org/r/87d69aab88c14d65ae1e7be55050d1b689b59b4b.1429402494.git.len.br...@intel.com You could ask around whether a timeout is needed between the assertion and deassertion of INIT done by the BSP when booting other cores. Sure, I'll ask around and try mdelay(0) on some systems as well. I can gather Fam15h, Fam16h but don't have K8's or older. Will let you know how it goes. -Aravind. If not, we probably should convert, at least modern AMD machines, to the no-delay default. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/1] speeding up cpu_up()
On Fri, May 01, 2015 at 02:42:39PM -0700, Len Brown wrote: On Mon, Apr 20, 2015 at 12:15 AM, Ingo Molnar mi...@kernel.org wrote: So instead of playing games with an ancient delay, I'd suggest we install the 10 msec INIT assertion wait as a platform quirk instead, and activate it for all CPUs/systems that we think might need it, with a sufficiently robust and future-proof quirk cutoff condition. New systems won't have the quirk active and thus won't have to have this delay configurable either. Okay, at this time, I think the quirk would apply to: 1. Intel family 5 (original pentium) -- some may actually need the quirk 2. Intel family F (pentium4) -- mostly b/c I don't want to bother finding/testing p4 3. All AMD (happy to narrow down, if somebody can speak for AMD) Aravind and I could probably test on a couple of AMD boxes to narrow down. @Aravind, see here: https://lkml.kernel.org/r/87d69aab88c14d65ae1e7be55050d1b689b59b4b.1429402494.git.len.br...@intel.com You could ask around whether a timeout is needed between the assertion and deassertion of INIT done by the BSP when booting other cores. If not, we probably should convert, at least modern AMD machines, to the no-delay default. I'd keep the cmdline override, in case we break something, or somebody wants to optimize/test. (Though I'll update units to usec, rather than msec., so we can go below 1ms without going to 0) I don't think we need the config option, just a #define to document the quirk. What do you think? Len Brown, Intel Open Source Technology Center -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/1] speeding up cpu_up()
On Mon, Apr 20, 2015 at 12:15 AM, Ingo Molnar mi...@kernel.org wrote: So instead of playing games with an ancient delay, I'd suggest we install the 10 msec INIT assertion wait as a platform quirk instead, and activate it for all CPUs/systems that we think might need it, with a sufficiently robust and future-proof quirk cutoff condition. New systems won't have the quirk active and thus won't have to have this delay configurable either. Okay, at this time, I think the quirk would apply to: 1. Intel family 5 (original pentium) -- some may actually need the quirk 2. Intel family F (pentium4) -- mostly b/c I don't want to bother finding/testing p4 3. All AMD (happy to narrow down, if somebody can speak for AMD) I'd keep the cmdline override, in case we break something, or somebody wants to optimize/test. (Though I'll update units to usec, rather than msec., so we can go below 1ms without going to 0) I don't think we need the config option, just a #define to document the quirk. What do you think? Len Brown, Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/1] speeding up cpu_up()
* Len Brown wrote: > The following patch... > > [PATCH 1/1] x86: replace cpu_up hard-coded mdelay with variable > > enables reducing cpu_up() time by 10ms on modern systems. > > This means that for every processor in the system, > boot-time and resume-time can be reduced by 10ms per-processor. > > Once this patch is accepted, I'll send a subsequent patch > to update the default delay, as appropriate. > > thanks, > Len Brown, Intel Open Source Technology Center So instead of playing games with an ancient delay, I'd suggest we install the 10 msec INIT assertion wait as a platform quirk instead, and activate it for all CPUs/systems that we think might need it, with a sufficiently robust and future-proof quirk cutoff condition. New systems won't have the quirk active and thus won't have to have this delay configurable either. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/1] speeding up cpu_up()
* Len Brown l...@kernel.org wrote: The following patch... [PATCH 1/1] x86: replace cpu_up hard-coded mdelay with variable enables reducing cpu_up() time by 10ms on modern systems. This means that for every processor in the system, boot-time and resume-time can be reduced by 10ms per-processor. Once this patch is accepted, I'll send a subsequent patch to update the default delay, as appropriate. thanks, Len Brown, Intel Open Source Technology Center So instead of playing games with an ancient delay, I'd suggest we install the 10 msec INIT assertion wait as a platform quirk instead, and activate it for all CPUs/systems that we think might need it, with a sufficiently robust and future-proof quirk cutoff condition. New systems won't have the quirk active and thus won't have to have this delay configurable either. Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/1] speeding up cpu_up()
The following patch... [PATCH 1/1] x86: replace cpu_up hard-coded mdelay with variable enables reducing cpu_up() time by 10ms on modern systems. This means that for every processor in the system, boot-time and resume-time can be reduced by 10ms per-processor. Once this patch is accepted, I'll send a subsequent patch to update the default delay, as appropriate. thanks, Len Brown, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/1] speeding up cpu_up()
The following patch... [PATCH 1/1] x86: replace cpu_up hard-coded mdelay with variable enables reducing cpu_up() time by 10ms on modern systems. This means that for every processor in the system, boot-time and resume-time can be reduced by 10ms per-processor. Once this patch is accepted, I'll send a subsequent patch to update the default delay, as appropriate. thanks, Len Brown, Intel Open Source Technology Center -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
