hihi, doug -
> Doug Ambrisko <[EMAIL PROTECTED]> wrote
> ...
> The assumption with this calculation is that st & it tend to be
> small compared to tt so the 1024 X shouldn't overflow much.
> ...
> [EMAIL PROTECTED] wrote:
> | ...but i'm a little worried that the 1024 multiplications aren't
> | large enough when tt gets really large
> | > Doug Ambrisko <[EMAIL PROTECTED]> wrote
> | > ...
> | > /* Subdivide tu. try to becareful of overflow */
> | > su = tu * (st * 1024 / tt) / 1024;
> | > iu = tu * (it * 1024 / tt) / 1024;
> | > uu = tu - (su + iu);
> | > ...
i'm not so worried about the overflow limit (that's what the mathematical
analysis is intended to discover, and i assume that the bound is large enough
to ignore the issue - that is the really clever part about computing su and iu
first instead of uu), but the underflow - if st and it are small enough and tt
is large enough, these equations produce 0 for both su and iu (and the
reported percentage will rightly be 0.00%, but i want to see the rest of the
detail for my time models)
what i think i'll do is try out my set of if-protected equations, but with
your choice of computing su and iu - that ought to avoid both problems
#define TOOBIG 45254834 /* 32*sqrt(2)*10^6 */
if (tt >= TOOBIG && tu >= tt)
{
u_int64_t q, r;
q = tu / tt;
r = tu % tt;
su = (q * st) + (r * st) / tt;
iu = (q * it) + (r * it) / tt;
}
else {
su = (tu * st) / tt;
iu = (tu * it) / tt;
}
uu = tu - (su + iu);
of course, JUST using the lines
su = (tu * st) / tt;
iu = (tu * it) / tt;
uu = tu - (su + iu);
will help a lot already - perhaps this much should be done right now
(according to the usual committment protocols) while we analyze the various
alternative suggestions for improvement (or are there high-utilization
processes that are more system time than user time?)
general question - is it (interrupt time) where the unreported time is when
user and system percentages add up to much less than 100%? i assume that the
monotonicity rules are what makes programs report over 100% utilization (which
i get occasionally, but only on very short programs)
more later,
cal
Chris Landauer
Aerospace Integration Science Center
The Aerospace Corporation
[EMAIL PROTECTED]
PS - i'm sorry i don't speak "patch" well enough yet, but i will eventually
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
