From owner-svn-src-head@FreeBSD.ORG Mon Oct 18 20:28:20 2010 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4052A106564A; Mon, 18 Oct 2010 20:28:20 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 390D58FC0C; Mon, 18 Oct 2010 20:28:18 +0000 (UTC) Received: by bwz16 with SMTP id 16so50430bwz.13 for ; Mon, 18 Oct 2010 13:28:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=1yO7oI4ob14StQJvo3N913YV9ZuB7WiFOsNsXlLLLBs=; b=UHY5YpGNqVc7dioo7hWQ+rEwziNud9igdTSwPzyeU7rLGE3LVBft1cOhnNed9jSSrs QSn9D4XaB8L0vqLRKFZQWylNNmNULRjSsbEo750Ap0oZ7rC2FhVAP/msqUrheWVSlrSP /pw5peWVRp6iVIHvyB9NV/47U9nV4Hqsg2DxY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=a9IvMnnkgFNyGjgbOjOrUY2Oz3+rE9LWSmLa+nDMYtOTf8yafyzoB4RyOMWHj1Foia xB/Zq9/INIfRvRrqXHDbAtGL9kaDhacyoSN5VDNDFm0T1qeP+TtGjJl9aw6f21yxUBPB n6U+1AOl89dBgmXC3Zm9ydQeqIdGMYVg4sHnw= Received: by 10.204.24.144 with SMTP id v16mr4817449bkb.137.1287433696962; Mon, 18 Oct 2010 13:28:16 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 4sm14496041bki.1.2010.10.18.13.28.14 (version=SSLv3 cipher=RC4-MD5); Mon, 18 Oct 2010 13:28:15 -0700 (PDT) Sender: Alexander Motin Message-ID: <4CBCADDD.5070109@FreeBSD.org> Date: Mon, 18 Oct 2010 23:28:13 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Marius Strobl References: <201010171646.o9HGks2U038501@svn.freebsd.org> <201010181003.13045.jhb@freebsd.org> <20101018190615.GL1416@alchemy.franken.de> In-Reply-To: <20101018190615.GL1416@alchemy.franken.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, John Baldwin Subject: Re: svn commit: r213985 - head/sys/sparc64/sparc64 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 20:28:20 -0000 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