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 :)
regards
john
PS all that hres_lock jiggery pokery in that code is somewhat dubious
too...
