* [PATCH] x86: hpet: Don't default CONFIG_HPET_TIMER to be y for X86_64 @ 2014-03-27 7:45 Feng Tang 2014-03-27 11:02 ` Clemens Ladisch 0 siblings, 1 reply; 8+ messages in thread From: Feng Tang @ 2014-03-27 7:45 UTC (permalink / raw) To: tglx, mingo, hpa, linux-kernel; +Cc: Feng Tang On many new phone/tablet platforms like Baytrail/Merrifield etc, the HPET are either defeatured or has some problem to be used as a reliable timer. As these platforms also have X86_64, we should not make HPET_TIMER default y for all X86_64. Signed-off-by: Feng Tang <feng.tang@intel.com> --- arch/x86/Kconfig | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 0af5250..269bd47 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -695,8 +695,7 @@ config X86_CYCLONE_TIMER source "arch/x86/Kconfig.cpu" config HPET_TIMER - def_bool X86_64 - prompt "HPET Timer Support" if X86_32 + prompt "HPET Timer Support" ---help--- Use the IA-PC HPET (High Precision Event Timer) to manage time in preference to the PIT and RTC, if a HPET is -- 1.7.0.4 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH] x86: hpet: Don't default CONFIG_HPET_TIMER to be y for X86_64 2014-03-27 7:45 [PATCH] x86: hpet: Don't default CONFIG_HPET_TIMER to be y for X86_64 Feng Tang @ 2014-03-27 11:02 ` Clemens Ladisch 2014-03-27 19:52 ` Andy Lutomirski 0 siblings, 1 reply; 8+ messages in thread From: Clemens Ladisch @ 2014-03-27 11:02 UTC (permalink / raw) To: Feng Tang, tglx, mingo, hpa, linux-kernel Feng Tang wrote: > On many new phone/tablet platforms like Baytrail/Merrifield etc, > the HPET are either defeatured or has some problem to be used > as a reliable timer. As these platforms also have X86_64, we > should not make HPET_TIMER default y for all X86_64. The help text still says: | You can safely choose Y here. [...] | Choose N to continue using the legacy 8254 timer. Are these statements still true for those platforms? Regards, Clemens ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] x86: hpet: Don't default CONFIG_HPET_TIMER to be y for X86_64 2014-03-27 11:02 ` Clemens Ladisch @ 2014-03-27 19:52 ` Andy Lutomirski 2014-03-27 21:27 ` John Stultz 2014-03-28 2:48 ` Feng Tang 0 siblings, 2 replies; 8+ messages in thread From: Andy Lutomirski @ 2014-03-27 19:52 UTC (permalink / raw) To: Clemens Ladisch, Feng Tang, tglx, mingo, hpa, linux-kernel On 03/27/2014 04:02 AM, Clemens Ladisch wrote: > Feng Tang wrote: >> On many new phone/tablet platforms like Baytrail/Merrifield etc, >> the HPET are either defeatured or has some problem to be used >> as a reliable timer. As these platforms also have X86_64, we >> should not make HPET_TIMER default y for all X86_64. Wouldn't it be better to fix the hpet driver so that the hpet doesn't used on these platforms? > > The help text still says: > | You can safely choose Y here. [...] > | Choose N to continue using the legacy 8254 timer. > > Are these statements still true for those platforms? They aren't true for modern desktop and server platforms -- the TSC is used regardless of hpet availability. > > > Regards, > Clemens > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] x86: hpet: Don't default CONFIG_HPET_TIMER to be y for X86_64 2014-03-27 19:52 ` Andy Lutomirski @ 2014-03-27 21:27 ` John Stultz 2014-03-27 21:33 ` Andy Lutomirski 2014-03-28 2:43 ` Feng Tang 2014-03-28 2:48 ` Feng Tang 1 sibling, 2 replies; 8+ messages in thread From: John Stultz @ 2014-03-27 21:27 UTC (permalink / raw) To: Andy Lutomirski Cc: Clemens Ladisch, Feng Tang, Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Linux Kernel Mailing List On Thu, Mar 27, 2014 at 12:52 PM, Andy Lutomirski <luto@amacapital.net> wrote: > On 03/27/2014 04:02 AM, Clemens Ladisch wrote: >> Feng Tang wrote: >> The help text still says: >> | You can safely choose Y here. [...] >> | Choose N to continue using the legacy 8254 timer. >> >> Are these statements still true for those platforms? > > They aren't true for modern desktop and server platforms -- the TSC is > used regardless of hpet availability. While I suspect the comment above is in relation to the non-apic timer. But with respect to timekeeping, our point is true assuming the TSC isn't mucked up by the BIOS. My 1yr old i7-3930k single socket system still has some wonky BIOS bug that offsets the boot core's TSC. And that's intel's bios, so I can only imagine other vendors have found other ways to cause trouble. So yea, the hpet availability for timekeeping is still important, as the TSC can still be problematic. thanks -john ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] x86: hpet: Don't default CONFIG_HPET_TIMER to be y for X86_64 2014-03-27 21:27 ` John Stultz @ 2014-03-27 21:33 ` Andy Lutomirski 2014-03-27 21:52 ` John Stultz 2014-03-28 2:43 ` Feng Tang 1 sibling, 1 reply; 8+ messages in thread From: Andy Lutomirski @ 2014-03-27 21:33 UTC (permalink / raw) To: John Stultz Cc: Clemens Ladisch, Feng Tang, Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Linux Kernel Mailing List On Thu, Mar 27, 2014 at 2:27 PM, John Stultz <john.stultz@linaro.org> wrote: > On Thu, Mar 27, 2014 at 12:52 PM, Andy Lutomirski <luto@amacapital.net> wrote: >> On 03/27/2014 04:02 AM, Clemens Ladisch wrote: >>> Feng Tang wrote: >>> The help text still says: >>> | You can safely choose Y here. [...] >>> | Choose N to continue using the legacy 8254 timer. >>> >>> Are these statements still true for those platforms? >> >> They aren't true for modern desktop and server platforms -- the TSC is >> used regardless of hpet availability. > > While I suspect the comment above is in relation to the non-apic > timer. But with respect to timekeeping, our point is true assuming the > TSC isn't mucked up by the BIOS. My 1yr old i7-3930k single socket > system still has some wonky BIOS bug that offsets the boot core's TSC. > And that's intel's bios, so I can only imagine other vendors have > found other ways to cause trouble. Is this, perhaps, an MSI X79A-GD65 (8D) (MS-7760)? If so, there's a fixed BIOS. > > So yea, the hpet availability for timekeeping is still important, as > the TSC can still be problematic. Is HPET really that much better than acpi_pm? I can read my HPET in ~584ns (vdso) or ~649ns (syscall) and my acpi_pm in 753ns. So it's better, but not by a whole lot. But yes, I see no good reason to disable it, except specifically on systems where there are known bugs. > > thanks > -john -- Andy Lutomirski AMA Capital Management, LLC ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] x86: hpet: Don't default CONFIG_HPET_TIMER to be y for X86_64 2014-03-27 21:33 ` Andy Lutomirski @ 2014-03-27 21:52 ` John Stultz 0 siblings, 0 replies; 8+ messages in thread From: John Stultz @ 2014-03-27 21:52 UTC (permalink / raw) To: Andy Lutomirski Cc: Clemens Ladisch, Feng Tang, Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Linux Kernel Mailing List, Dave Hansen On 03/27/2014 02:33 PM, Andy Lutomirski wrote: > On Thu, Mar 27, 2014 at 2:27 PM, John Stultz <john.stultz@linaro.org> wrote: >> On Thu, Mar 27, 2014 at 12:52 PM, Andy Lutomirski <luto@amacapital.net> wrote: >>> On 03/27/2014 04:02 AM, Clemens Ladisch wrote: >>>> Feng Tang wrote: >>>> The help text still says: >>>> | You can safely choose Y here. [...] >>>> | Choose N to continue using the legacy 8254 timer. >>>> >>>> Are these statements still true for those platforms? >>> They aren't true for modern desktop and server platforms -- the TSC is >>> used regardless of hpet availability. >> While I suspect the comment above is in relation to the non-apic >> timer. But with respect to timekeeping, our point is true assuming the >> TSC isn't mucked up by the BIOS. My 1yr old i7-3930k single socket >> system still has some wonky BIOS bug that offsets the boot core's TSC. >> And that's intel's bios, so I can only imagine other vendors have >> found other ways to cause trouble. > Is this, perhaps, an MSI X79A-GD65 (8D) (MS-7760)? If so, there's a fixed BIOS. Actually, an Intel DX79TO. I've harangued some folks I know, but no fixes for the BIOS have been released. >> So yea, the hpet availability for timekeeping is still important, as >> the TSC can still be problematic. > Is HPET really that much better than acpi_pm? I can read my HPET in > ~584ns (vdso) or ~649ns (syscall) and my acpi_pm in 753ns. So it's > better, but not by a whole lot. I know on older hardware it was a bigger win. I'd have to look at what my current system does. > But yes, I see no good reason to disable it, except specifically on > systems where there are known bugs. Agreed. thanks -john ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] x86: hpet: Don't default CONFIG_HPET_TIMER to be y for X86_64 2014-03-27 21:27 ` John Stultz 2014-03-27 21:33 ` Andy Lutomirski @ 2014-03-28 2:43 ` Feng Tang 1 sibling, 0 replies; 8+ messages in thread From: Feng Tang @ 2014-03-28 2:43 UTC (permalink / raw) To: John Stultz Cc: Andy Lutomirski, Clemens Ladisch, Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Linux Kernel Mailing List On Thu, Mar 27, 2014 at 02:27:26PM -0700, John Stultz wrote: > On Thu, Mar 27, 2014 at 12:52 PM, Andy Lutomirski <luto@amacapital.net> wrote: > > On 03/27/2014 04:02 AM, Clemens Ladisch wrote: > >> Feng Tang wrote: > >> The help text still says: > >> | You can safely choose Y here. [...] > >> | Choose N to continue using the legacy 8254 timer. > >> > >> Are these statements still true for those platforms? > > > > They aren't true for modern desktop and server platforms -- the TSC is > > used regardless of hpet availability. > > While I suspect the comment above is in relation to the non-apic > timer. But with respect to timekeeping, our point is true assuming the > TSC isn't mucked up by the BIOS. My 1yr old i7-3930k single socket > system still has some wonky BIOS bug that offsets the boot core's TSC. > And that's intel's bios, so I can only imagine other vendors have > found other ways to cause trouble. > > So yea, the hpet availability for timekeeping is still important, as > the TSC can still be problematic. Yes, agreed. My patch only provides a way to disable HPET for some specific platforms :) Thanks, Feng ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] x86: hpet: Don't default CONFIG_HPET_TIMER to be y for X86_64 2014-03-27 19:52 ` Andy Lutomirski 2014-03-27 21:27 ` John Stultz @ 2014-03-28 2:48 ` Feng Tang 1 sibling, 0 replies; 8+ messages in thread From: Feng Tang @ 2014-03-28 2:48 UTC (permalink / raw) To: Andy Lutomirski; +Cc: Clemens Ladisch, tglx, mingo, hpa, linux-kernel On Thu, Mar 27, 2014 at 12:52:57PM -0700, Andy Lutomirski wrote: > On 03/27/2014 04:02 AM, Clemens Ladisch wrote: > > Feng Tang wrote: > >> On many new phone/tablet platforms like Baytrail/Merrifield etc, > >> the HPET are either defeatured or has some problem to be used > >> as a reliable timer. As these platforms also have X86_64, we > >> should not make HPET_TIMER default y for all X86_64. > > Wouldn't it be better to fix the hpet driver so that the hpet doesn't > used on these platforms? > > > > > The help text still says: > > | You can safely choose Y here. [...] > > | Choose N to continue using the legacy 8254 timer. > > > > Are these statements still true for those platforms? > > They aren't true for modern desktop and server platforms -- the TSC is > used regardless of hpet availability. The way of using TSC varies depends on the generations of platforms. Thomas Gleixner once gave a very good description, which link I personally bookmarked, and would share here: https://lkml.org/lkml/2013/5/8/202 Thanks, Feng ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-03-28 2:49 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-03-27 7:45 [PATCH] x86: hpet: Don't default CONFIG_HPET_TIMER to be y for X86_64 Feng Tang 2014-03-27 11:02 ` Clemens Ladisch 2014-03-27 19:52 ` Andy Lutomirski 2014-03-27 21:27 ` John Stultz 2014-03-27 21:33 ` Andy Lutomirski 2014-03-27 21:52 ` John Stultz 2014-03-28 2:43 ` Feng Tang 2014-03-28 2:48 ` Feng Tang
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox