Date: Tue, 05 Feb 2002 20:09:11 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: nate@yogotech.com (Nate Williams) Cc: John Polstra <jdp@polstra.com>, hackers@FreeBSD.ORG Subject: Re: A question about timecounters Message-ID: <92033.1012936151@critter.freebsd.dk> In-Reply-To: Your message of "Tue, 05 Feb 2002 12:04:45 MST." <15456.11469.659090.290513@caddis.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <15456.11469.659090.290513@caddis.yogotech.com>, Nate Williams writes:
>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.
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 :-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
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?92033.1012936151>