Date: Mon, 18 Oct 2010 10:03:12 -0400 From: John Baldwin <jhb@freebsd.org> To: Marius Strobl <marius@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r213985 - head/sys/sparc64/sparc64 Message-ID: <201010181003.13045.jhb@freebsd.org> In-Reply-To: <201010171646.o9HGks2U038501@svn.freebsd.org> References: <201010171646.o9HGks2U038501@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201010181003.13045.jhb>