* [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