Can't this code can just read the TSC directly with something like
tsc_read(). :-) Both gethrtime() calls are done with interrupts
disabled on the same CPU just before and after going into
Deep C-State. Interrups are not enabled between the two
gethrtime() calls. The two TSC values will be accurate with each
other during this interval. A difference is computed,
so tsc_sync_tick_delta is not needed.
The TSC difference will have to be scaled to nonoseconds
with something like tsc_scalehrtime.
Regards,
Bill
P.S. Aubrey originally used the pm timer for platforms
with an unstable TSC during Deep C-State.
On 09/05/08 10:18, Eric Saxe wrote:
> John Levon wrote:
>
>> On Fri, Sep 05, 2008 at 09:33:19AM -0700, Eric Saxe wrote:
>>
>>
>>
>>>>> Author: Aubrey Li <aubrey.li at intel.com>
>>>>> Repository: /hg/tesla/hpet_pcplusmp
>>>>> Latest revision: 2647c4ca1125adbad82c2bac66bd7a9af39baf2a
>>>>> Total changesets: 1
>>>>> Log message:
>>>>> Revert 7422, since gethrtime need to disable
>>>>> interrupt to prevent migration, it is more
>>>>> expensive than reading PM timer
>>>>>
>>>>> Files:
>>>>> update: usr/src/uts/i86pc/io/cpudrv/cpu_acpi.c
>>>>> update: usr/src/uts/i86pc/io/cpudrv/cpu_idle.c
>>>>> update: usr/src/uts/i86pc/sys/cpu_acpi.h
>>>>>
>>>>>
>>>>>
>>>> I think that interrupt disable can just be an increment and decrement of
>>>> ->t_preempt, though. Any reasons why not?
>>>>
>>>>
>>>>
>>> Right, please see the kpreempt_disable() / kpreempt_enable() macros.
>>> With kernel preemption disabled using the above macros, the calling
>>> thread cannot be preempted, and thus cannot migrate....unless it
>>> explicitly does something to surrender the CPU (such as trying to grab a
>>> lock). kpreempt_disable / enable are very inexpensive operations
>>> otherwise. :)
>>>
>>>
>> Slightly more tricky here. The reason it uses cli/sti at all is because
>> kpreempt_enable() will indeed trigger a pre-emption, which is verboten
>> here (since we may have come in via a fast-trap, and we don't have any
>> of the RUPDATE_PENDING fun). So it really needs to be:
>>
>> curthread->t_preempt++;
>> ...
>> curthread->t_preempt--;
>>
>> like in xpv_timestamp.c. Unless I've got it totally wrong, of course :)
>>
>>
> That's what I get for commenting without looking at the code. :)
>
> Thanks John...
> -Eric
> _______________________________________________
> tesla-dev mailing list
> tesla-dev at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/tesla-dev
>
