> >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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
