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
