From owner-freebsd-current@FreeBSD.ORG Fri Jul 23 22:48:38 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2158116A4CE; Fri, 23 Jul 2004 22:48:38 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D350C43D53; Fri, 23 Jul 2004 22:48:37 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) i6NMmYds040931; Fri, 23 Jul 2004 15:48:35 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i6NMmXtY040928; Fri, 23 Jul 2004 15:48:33 -0700 (PDT) (envelope-from dillon) Date: Fri, 23 Jul 2004 15:48:33 -0700 (PDT) From: Matthew Dillon Message-Id: <200407232248.i6NMmXtY040928@apollo.backplane.com> To: Bruce Evans References: <20040721081310.GJ22160@freebsd3.cimlogic.com.au> <20040721220405.Y2346@epsplex.bde.org> <20040722225952.S1704@epsplex.bde.org> cc: current@freebsd.org Subject: Re: nanosleep returning early X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2004 22:48:38 -0000 :> Bruce, have you seen this document: ? :> I'm not looking for a critique here. The document talks about the sleep :> overruns in various operatingg systems. There is a patch that was applied :> to DragonFly which aplies to the FreeBSD code base too. : :I just looked. It doesn't apply to FreeBSD. Adding 1 to the tick :count in tvtohz() is necessary in many places in FreeBSD (e.g., for :itimers). It happens to be just an optimizatiom in nanosleep1() for :the reasons you mentioned above (going around again fixes any :underestimate of the tick count, and overestimating by 1 avoids going :around again in most cases). :... :I believe dragonflybsd has high resolution timeouts which make the :issues different. `tick' could be somthing like 10**6 and tick counts :in microseconds would be so large that off by 1 errors in them would :be too small to measure. : :Bruce :_______________________________________________ That document doesn't really apply to us anymore either, but I keep it up because it's excellent teaching material (esp. the graphs). Yah, DFly's nanosleep now uses our SYSTIMER subsystem and is no longer limited by the granularity of the tick clock. The SYSTIMER subsystem is a general purpose, high resolution, MP-friendly, one-shot and periodic timer module. We use it for nanosleep, interrupt rate limiting, and to distribute the various system clocks (hardclock, statclock, schedclock, and profiling primarily). The callback interface kinda looks like FAST-INT in FreeBSDspeak, though the abstraction is considerably more refined in DFly. The interesting issue we have in regards to nanosleep is where to cut it off and how closely to try to match the requested timeout against the actual timeout based on the overhead of various mechanisms. If the request is too small to be worth the overhead of setting up a systimer, we try a yield instead. It's an interesting issue. I'd recommend that you guys port it, because you desparately need to rewrite your clock distribution code, but its dependant on IPI messaging (as are most DFly subsytems) and so you need the IPI messaging abstraction first. -Matt Matthew Dillon