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

[Marius Strobl]

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.

Marius