Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 18 Oct 2010 23:28:13 +0300
From:      Alexander Motin <mav@FreeBSD.org>
To:        Marius Strobl <marius@alchemy.franken.de>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, John Baldwin <jhb@freebsd.org>
Subject:   Re: svn commit: r213985 - head/sys/sparc64/sparc64
Message-ID:  <4CBCADDD.5070109@FreeBSD.org>
In-Reply-To: <20101018190615.GL1416@alchemy.franken.de>
References:  <201010171646.o9HGks2U038501@svn.freebsd.org> <201010181003.13045.jhb@freebsd.org> <20101018190615.GL1416@alchemy.franken.de>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

At this time on most (all?) platforms critical section is grabbed by MD
interrupt code. It is important to be there, as soon as there touched
td_intr_nesting_level and td_intr_frame fields of curthread. We can't
allow thread migration until all counted interrupt handlers complete.

-- 
Alexander Motin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CBCADDD.5070109>