Date: Tue, 5 Feb 2002 12:18:59 -0700 From: Nate Williams <nate@yogotech.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: nate@yogotech.com (Nate Williams), John Polstra <jdp@polstra.com>, hackers@FreeBSD.ORG Subject: Re: A question about timecounters Message-ID: <15456.12323.943290.212726@caddis.yogotech.com> In-Reply-To: <92033.1012936151@critter.freebsd.dk> References: <15456.11469.659090.290513@caddis.yogotech.com> <92033.1012936151@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
> >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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15456.12323.943290.212726>