> > cpu times were miscalculated because 'usecs' could go -ve...
> > There is still a problem that 'st = (u * st) / tot;' can overflow,
> > but that is harder to fix, and requires cpu times of ~5days.
> 
> I'm curious about this 5 day case - it's not that hard to bring up that
> much cpu time (eg, leave a browser running for two or three weeks)...

The problem is that 'u * st' and 'u * ut' can overflows 64bits.
'u' is a time in usecs, 'st/ut' a count of ticks at 'stathz'.
If a process spent all its time in (say) usermode, and picked up
an average number of ticks for 's' seconds then:
	u = s * 1000000;
	ut = s * stathz
	u * ut = s^2 * 1000000 * stathz
this exceeds 2^64 when:
	s = sqrt(2^64 / 1000000 / stathz)
if stathz = 100,  s = 429497 = 4.97 days
if stathz = 1000, s = 135819 = 1.57 days

This whole sum could also do with being coded without all the 64bit divides.
Not least because the __uqdivrem call we have seems to be a chunk of C.
Which means it isn't optimised for the 64 by 32 case (a cpu instruction
on many systems).

	David

-- 
David Laight: david@l8s.co.uk