svn commit: r213985 - head/sys/sparc64/sparc64

[John Baldwin]

On Monday, October 18, 2010 3:06:15 pm Marius Strobl wrote:
> On Mon, Oct 18, 2010 at 10:03:12AM -0400, John Baldwin wrote:
> > On Sunday, October 17, 2010 12:46:54 pm Marius Strobl wrote:
> > > Author: marius
> > > Date: Sun Oct 17 16:46:54 2010
> > > New Revision: 213985
> > > URL: http://svn.freebsd.org/changeset/base/213985
> > > 
> > > Log:
> > >   - In oneshot-mode it doesn't make sense to try to compensate the clock
> > >     drift in order to achieve a more stable clock as the tick intervals may
> > >     vary in the first place. In fact I haven't seen this code kick in when
> > >     in oneshot-mode so just skip it in that case.
> > >   - There's no need to explicitly stop the (S)TICK counter in oneshot-mode
> > >     with every tick as it just won't trigger again with the (S)TICK compare
> > >     register set to a value in the past (with a wrap-around once every ~195
> > >     years of uptime at 1.5 GHz this isn't something we have to worry about
> > >     in practice).
> > >   - Given that we'll disable interrupts completely anyway there's no
> > >     need to enter critical sections.
> > 
> > This last is not entirely true.  The purpose of the critical section is to 
> > prevent the kernel from preempting to the softclock swi thread until all of 
> > the hardclock handler has finished execution.  Thus, places that actually 
> > actually call hardclock() should probably still be wrapped in a critical
> > section.
> > 
> 
> It's currently unclear to me how on architectures converted to the
> event timer world order hardclock() is called eventually but in any case
> shouldn't it be the responsibility of the code actually calling it (or
> the equivalent code) to wrap it in a critical section instead then? After
> all the MD part just enrolls in calling _something_ in one-shot and/or
> periodic mode without knowing what it actually calls (and IMO it also
> should no longer need to). In handleevents() of kern_clocksource.c
> hardclock_anycpu() is called so i think that is what actually needs to
> be wrapped in a critical section.

Hmm, we've previously done the critical section in the MD code instead of in
hardclock() itself so that if a timer needed to be reprogrammed or interrupt
acknowledged as much of that as possible could happen before being preempted
(or put another way, the preemption to softclock was deferred until all
that stuff had completed).  I don't know if handleevents() is at a sufficient
level to know for certain that everything is done such that it is safe to
preempt when critical_exit() is invoked.

-- 
John Baldwin