On Mon, 6 Jul 2015, Adrian Hunter wrote:
> On 22/06/15 16:14, Thomas Gleixner wrote:
> > On Mon, 22 Jun 2015, Adrian Hunter wrote:
> >> On 03/06/15 19:23, Thomas Gleixner wrote:
> >>> On Wed, 3 Jun 2015, Adrian Hunter wrote:
> >>>
> On 03/06/15 06:30, Andi Kleen wrote:
> >> Then the chang
On 22/06/15 16:14, Thomas Gleixner wrote:
> On Mon, 22 Jun 2015, Adrian Hunter wrote:
>> On 03/06/15 19:23, Thomas Gleixner wrote:
>>> On Wed, 3 Jun 2015, Adrian Hunter wrote:
>>>
On 03/06/15 06:30, Andi Kleen wrote:
>> Then the changelog should say that I think. The current text says
>>>
Adrian Hunter wrote:
> On 03/06/15 19:23, Thomas Gleixner wrote:
>> I'm certainly happy to apply this one.
>
> George Spelvin began investigating improving quick_pit_calibrate() but Ingo
> anyway suggested this patch as the first, so can this be applied?
Acked-by: George Spelvin
It's currentl
On Mon, 22 Jun 2015, Adrian Hunter wrote:
> On 03/06/15 19:23, Thomas Gleixner wrote:
> > On Wed, 3 Jun 2015, Adrian Hunter wrote:
> >
> >> On 03/06/15 06:30, Andi Kleen wrote:
> Then the changelog should say that I think. The current text says
> "Fast TSC calibration will always fail",
On 03/06/15 19:23, Thomas Gleixner wrote:
> On Wed, 3 Jun 2015, Adrian Hunter wrote:
>
>> On 03/06/15 06:30, Andi Kleen wrote:
Then the changelog should say that I think. The current text says
"Fast TSC calibration will always fail", which, to me, suggests that
either the slow cali
And, for interest's sake, I went to a somewhat older machine: a 2008
MSI K9A2 platinum with DDR2, a Socket 939 AMD processor, SB600 south
bridge and (most importantly for this) a Fintek F71882FG super-IO
chip providing the PIT and RTC.
Anyway, the results are similar, again with the RTC being fast
> I'll run your code as well, to make sure it's not something bad in my code.
Here's a modified version that uses less stack space (no need to store
all 64 bits of a timestamp), and captures a window around an RTC periodic
flag edge to explore WTF is going on there.
commit 769eba0b589141edca3541c
* George Spelvin wrote:
> > Ingo Molnar wrote:
> >* George Spelvin wrote:
> >> Did you use rtc_cmos_read()? [...]
>
> > Yeah, so initially I did, but then after I noticed the overhead I
> > introduced:
> > which compiles to a single INB instruction.
> >
> > This didn't change the delay/cost
> Ingo Molnar wrote:
>* George Spelvin wrote:
>> Did you use rtc_cmos_read()? [...]
> Yeah, so initially I did, but then after I noticed the overhead I introduced:
> which compiles to a single INB instruction.
>
> This didn't change the delay/cost behavior.
>
> The numbers I cited, with tens of
* George Spelvin wrote:
> It's running at 3.4 GHz, so I expect 729478 ticks per 256 PIT counts, and
> 415039
> ticks per 8192 Hz RTC tick.
> (PIT reads are 1353 ns each, while RTC reads are 1142 ns.)
>
> RTC edge at 99172986783, delta 0, range 7764, iter 7
> RTC edge at 99173401719
* George Spelvin wrote:
> Ingo Molnar wrote:
> > - Alternatively, I also tried a different method: to set up the RTC
> > periodic IRQ during early boot, but not have an IRQ handler, polling
> > RTC_PF in the rtc_cmos_read(RTC_INTR_FLAGS) IRQ status byte.
> >
> > Unfortunately when I do thi
FWIW, I wrote my own test routine, with some interesting results.
It's a rude bodge and obviously not kernel-quality, but included if
anyone wants to mess with it.
My machine is an X79 motherboard with a common ITE IT8728F SuperIO
chip providing both RTC and PIT.
The intersting bit is that I can
On Thu, Jun 4, 2015 at 10:54 AM, George Spelvin wrote:
>
> Actually, the current code uses three timestamps: one before the last
> read of the unwanted value, one in the middle, and one after the
> read of the target value (bit set in this case).
Yes, right you are. All are valid and interesting.
On Thu, 4 Jun 2015 at 09:52:34, Linus Torvalds wrote:
> With the usual "have timestamp both before the read that shows the bit
> set, and after the read" so that you can estimate how big the error
> window is.
Actually, the current code uses three timestamps: one before the last
read of the unwant
On Thu, Jun 4, 2015 at 9:38 AM, George Spelvin wrote:
>
> Also, you don't have to enable interrupts in the RTC to get the PF bit
> set periodically. You only program the interval (register A lsbits),
> not the IRQ (register B bit 6). In fact, disabling the interrupt is
> probably safer.
Also, I
Ingo Molnar wrote:
> - Alternatively, I also tried a different method: to set up the RTC
> periodic IRQ during early boot, but not have an IRQ handler, polling
> RTC_PF in the rtc_cmos_read(RTC_INTR_FLAGS) IRQ status byte.
>
> Unfortunately when I do this then PIO based RTC accesses can take
* H. Peter Anvin wrote:
> [...]
>
> The RTC is probably the most reliable reference clock, in part because 32 kHz
> crystals are generally calibrated and extremely stable. However, to get more
> than 1 Hz frequency out of it you have to enable interrupts (which gets you
> to
> 8192 Hz). I
On 03/06/15 16:45, Linus Torvalds wrote:
> On Wed, Jun 3, 2015 at 1:13 AM, Adrian Hunter wrote:
>>
>> Yeah, so the (only?) downside is the 50ms wasted on Fast TSC
>> calibration. What about this?
>
> That's certainly simpler.
>
> What platform is this?
It's a prototype.
--
To unsubscribe fro
> Not guaranteed either, and I know for a fact there are platforms out
> there which synthesize the RTC clock.
Interesting! And surprising. Doesn't that take more battery power?
> Ah, I wasn't aware of the PF (not PE) bit. That suddenly makes it a lot
> more interesting. So polling for the PF
On 06/03/2015 11:29 AM, George Spelvin wrote:
>
> Indeed, it's the only one which is guaranteed a separate crystal.
> Many low-cost chipsets generate ALL other frequencies from one crystal
> with PLLs.
>
Not guaranteed either, and I know for a fact there are platforms out
there which synthesize
H. Peter Anvin wrote:
> The RTC is probably the most reliable reference clock, in part because
> 32 kHz crystals are generally calibrated and extremely stable. However,
> to get more than 1 Hz frequency out of it you have to enable interrupts
> (which gets you to 8192 Hz).
Indeed, it's the only o
On 06/03/2015 10:04 AM, Linus Torvalds wrote:
> On Wed, Jun 3, 2015 at 9:47 AM, Thomas Gleixner wrote:
>>
>>> Does anybody know what the base oscillator for HPET tends to be? Also,
>>
>> The most common frequency is 14.318180 MHz.
>
> I was more thinking along the lines of "which actually crystal
* Thomas Gleixner wrote:
> On Wed, 3 Jun 2015, Linus Torvalds wrote:
> > On Tue, Jun 2, 2015 at 11:20 PM, Ingo Molnar wrote:
> > >
> > > Given that Windows relies on the HPET for timekeeping, it might get more
> > > attention than the PIT?
> >
> > Does Windows actually do that? Becuase if so,
On Wed, Jun 3, 2015 at 9:47 AM, Thomas Gleixner wrote:
>
>> Does anybody know what the base oscillator for HPET tends to be? Also,
>
> The most common frequency is 14.318180 MHz.
I was more thinking along the lines of "which actually crystal is
driving it" than the frequency.
That said, that par
On Wed, 3 Jun 2015, Linus Torvalds wrote:
> On Tue, Jun 2, 2015 at 11:20 PM, Ingo Molnar wrote:
> > Given that Windows relies on the
> > HPET for timekeeping, it might get more attention than the PIT?
>
> Does Windows actually do that? Becuase if so, that's just about the
> strongest argument for
On Wed, 3 Jun 2015, Adrian Hunter wrote:
> On 03/06/15 06:30, Andi Kleen wrote:
> >> Then the changelog should say that I think. The current text says
> >> "Fast TSC calibration will always fail", which, to me, suggests that
> >> either the slow calibration will work or that the changelog message
On Wed, Jun 3, 2015 at 1:13 AM, Adrian Hunter wrote:
>
> Yeah, so the (only?) downside is the 50ms wasted on Fast TSC
> calibration. What about this?
That's certainly simpler.
What platform is this? Do you have access to hw people you can shake
down and ask what clock we can really _trust_?
On Tue, Jun 2, 2015 at 11:20 PM, Ingo Molnar wrote:
>
> and the HPET, which is pretty good as well, when available. In fact given that
> it's required to have a frequency of at least 10 MHz, and (unlike the PIT)
> has a
> pretty wide counter, it could be used for pretty accurate calibration as we
On 03/06/15 06:30, Andi Kleen wrote:
>> Then the changelog should say that I think. The current text says
>> "Fast TSC calibration will always fail", which, to me, suggests that
>> either the slow calibration will work or that the changelog message
>> should be changed.
>
> Ok. No, the slow calib
Linus wrote:
> The only *well-defined* clock in a modern PC seems to still remain the
> PIT. Yes, it's very sad. But all the other clocks tend to be
> untrustworthy for various reasons
Actually, there is one more: the CMOS RTC clock is quite reliably 32768 Hz.
The reas process is very similar, a
* Linus Torvalds wrote:
> On Tue, Jun 2, 2015 at 12:33 PM, Thomas Gleixner wrote:
> >
> > Is there really no smarter way to figure out the TSC frequency on
> > modern systems?
>
> Sadly, if there is, we have yet to find it.
>
> I don't think the mentioned intel_pstate thing gets it right eith
On Tue, Jun 2, 2015 at 12:33 PM, Thomas Gleixner wrote:
>
> Is there really no smarter way to figure out the TSC frequency on
> modern systems?
Sadly, if there is, we have yet to find it.
I don't think the mentioned intel_pstate thing gets it right either.
Yes, it gets some "theoretical frequenc
> Then the changelog should say that I think. The current text says
> "Fast TSC calibration will always fail", which, to me, suggests that
> either the slow calibration will work or that the changelog message
> should be changed.
Ok. No, the slow calibration works I believe.
-Andi
--
To unsubscr
On Tue, Jun 2, 2015 at 5:39 PM, Andi Kleen wrote:
> On Tue, Jun 02, 2015 at 05:21:27PM -0700, Andy Lutomirski wrote:
>> On Tue, Jun 2, 2015 at 4:38 PM, Andi Kleen wrote:
>> > On Tue, Jun 02, 2015 at 11:03:26PM +0200, Thomas Gleixner wrote:
>> >>
>> >>
>> >> On Tue, 2 Jun 2015, Andi Kleen wrote:
>
On Tue, Jun 02, 2015 at 05:21:27PM -0700, Andy Lutomirski wrote:
> On Tue, Jun 2, 2015 at 4:38 PM, Andi Kleen wrote:
> > On Tue, Jun 02, 2015 at 11:03:26PM +0200, Thomas Gleixner wrote:
> >>
> >>
> >> On Tue, 2 Jun 2015, Andi Kleen wrote:
> >>
> >> > > There's the code in tsc_msr.c. It should be
On Tue, Jun 2, 2015 at 4:38 PM, Andi Kleen wrote:
> On Tue, Jun 02, 2015 at 11:03:26PM +0200, Thomas Gleixner wrote:
>>
>>
>> On Tue, 2 Jun 2015, Andi Kleen wrote:
>>
>> > > There's the code in tsc_msr.c. It should be relatively
>> > > straightforward to extend it to cover everything that intel_p
On Tue, Jun 02, 2015 at 11:03:26PM +0200, Thomas Gleixner wrote:
>
>
> On Tue, 2 Jun 2015, Andi Kleen wrote:
>
> > > There's the code in tsc_msr.c. It should be relatively
> > > straightforward to extend it to cover everything that intel_pstate
> > > supports.
> >
> > That's a good idea, but w
On Tue, 2 Jun 2015, Andi Kleen wrote:
> > There's the code in tsc_msr.c. It should be relatively
> > straightforward to extend it to cover everything that intel_pstate
> > supports.
>
> That's a good idea, but we still need an always working fallback when the
> model number is not available. S
> There's the code in tsc_msr.c. It should be relatively
> straightforward to extend it to cover everything that intel_pstate
> supports.
That's a good idea, but we still need an always working fallback when the
model number is not available. So Adrian's patch is needed in any
case.
-Andi
--
a
On Tue, Jun 2, 2015 at 12:58 PM, Thomas Gleixner wrote:
> On Tue, 2 Jun 2015, Andi Kleen wrote:
>> On Tue, Jun 02, 2015 at 12:41:27PM -0700, Andy Lutomirski wrote:
>> > On Tue, Jun 2, 2015 at 12:33 PM, Thomas Gleixner
>> > wrote:
>> > > On Thu, 21 May 2015, Adrian Hunter wrote:
>> > >
>> > >> If
On Tue, 2 Jun 2015, Andi Kleen wrote:
> On Tue, Jun 02, 2015 at 12:41:27PM -0700, Andy Lutomirski wrote:
> > On Tue, Jun 2, 2015 at 12:33 PM, Thomas Gleixner wrote:
> > > On Thu, 21 May 2015, Adrian Hunter wrote:
> > >
> > >> If it takes longer than 12us to read the PIT counter lsb/msb,
> > >> the
On Tue, Jun 02, 2015 at 12:41:27PM -0700, Andy Lutomirski wrote:
> On Tue, Jun 2, 2015 at 12:33 PM, Thomas Gleixner wrote:
> > On Thu, 21 May 2015, Adrian Hunter wrote:
> >
> >> If it takes longer than 12us to read the PIT counter lsb/msb,
> >> then the error margin will never fall below 500ppm wi
On Tue, Jun 2, 2015 at 12:33 PM, Thomas Gleixner wrote:
> On Thu, 21 May 2015, Adrian Hunter wrote:
>
>> If it takes longer than 12us to read the PIT counter lsb/msb,
>> then the error margin will never fall below 500ppm within 50ms,
>> and Fast TSC calibration will always fail.
>
> So finally the
On Thu, 21 May 2015, Adrian Hunter wrote:
> If it takes longer than 12us to read the PIT counter lsb/msb,
> then the error margin will never fall below 500ppm within 50ms,
> and Fast TSC calibration will always fail.
So finally the legacy PIT emulation takes longer than the 30 years old
hardware
On Mon, 1 Jun 2015, Adrian Hunter wrote:
> On 21/05/15 10:55, Adrian Hunter wrote:
> > If it takes longer than 12us to read the PIT counter lsb/msb,
> > then the error margin will never fall below 500ppm within 50ms,
> > and Fast TSC calibration will always fail.
>
> Hi
>
> This does happen, so
On 21/05/15 10:55, Adrian Hunter wrote:
> If it takes longer than 12us to read the PIT counter lsb/msb,
> then the error margin will never fall below 500ppm within 50ms,
> and Fast TSC calibration will always fail.
Hi
This does happen, so it would be nice to have this fix.
Are there any comments?
If it takes longer than 12us to read the PIT counter lsb/msb,
then the error margin will never fall below 500ppm within 50ms,
and Fast TSC calibration will always fail.
This patch detects when that will happen and switches to using
a slightly different algorithm that takes advantage of the PIT's
l
47 matches
Mail list logo
