From owner-freebsd-hackers Tue Feb 5 11:19:45 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 3A8A837B417 for ; Tue, 5 Feb 2002 11:19:33 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id MAA04838; Tue, 5 Feb 2002 12:19:02 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g15JJ1W68973; Tue, 5 Feb 2002 12:19:01 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15456.12323.943290.212726@caddis.yogotech.com> Date: Tue, 5 Feb 2002 12:18:59 -0700 To: Poul-Henning Kamp Cc: nate@yogotech.com (Nate Williams), John Polstra , hackers@FreeBSD.ORG Subject: Re: A question about timecounters In-Reply-To: <92033.1012936151@critter.freebsd.dk> References: <15456.11469.659090.290513@caddis.yogotech.com> <92033.1012936151@critter.freebsd.dk> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > >How are issues (1) and (3) above different? > > > >ps. I'm just trying to understand, and am *NOT* trying to start a > >flame-war. :) :) :) > > If the starvation happens to hardclock() or rather tc_windup() the effect > will be cummulative and show up in permanent jumps in the output of date > for instance. In stable hardclock() is spl-protected so this would be > _really_ bad news. > > If the starvation happens in any of {micro|nano}[up]time() (but not the > "get&" variants!) the it will result in a single spurious reading. Ok, the bulb is starting to grow from dim to bright. :) > The premise for avoiding locking in the access functions to timecounters > where precisely that we could trust them to not be pre-empted for long > enough for the hardware to roll over, if this is not the case we loose > because the overflow in the hardware counter means that the timecounter > we calculate from is not valid for the delta we get from the hardware. > > I'm not sure this answers your question, if not it is not bad will, just > me not understanding the question :-) *grin* I think I understand the problem. Let me try to rephrase to make sure. 1) If we have an interrupt lockout (*NOT* due to time-counting code), then we'd have a problem since the hardclock would never get run. 2) If however, the locking done to protect the timecounter code happens to make getting/setting the timecounter take too long, we'd get similar results, but for *completely* different reasons. Let me be more precise. (1) cli(); /* Take a really long time doing something */ sti(); (2) /* Do something */ gettime(); /* Takes a really long time to complete */ The first is harder to track down/fix, simply because you don't know *who* the offender is. The latter is essentially the same problem to fix, but *may* be easier to fix since the offending code *IS* the timecounter code. Am I even close to understanding? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message