Summary: | time counter per process stops (syscall: getrusage) | ||
---|---|---|---|
Product: | Base System | Reporter: | Jakub Kruszona-Zawadzki <acid> |
Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> |
Status: | Closed DUPLICATE | ||
Severity: | Affects Only Me | CC: | emaste, jpaetzel |
Priority: | Normal | ||
Version: | Unspecified | ||
Hardware: | Any | ||
OS: | Any | ||
See Also: | https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227689 |
Description
Jakub Kruszona-Zawadzki
2005-03-17 20:50:02 UTC
On Thu, 17 Mar 2005, Jakub Kruszona-Zawadzki wrote:
>> Description:
> When a process is running for a long time (several days) time counter per process stops on value:
> ru_utime.tv_sec:305221
> ru_utime.tv_usec:322735
This may be the same bug as in PR 76972. Overflow occurs at about
48592008 ticks = 379625 seconds = 105 hours for a a process that consumes
100% of the CPU if the statclock frequency is 128 Hz (which is the default
and not easy to change). There is another overflow bug at 2^32 ticks = 388
days. This one is harder to fix. See PR 76972 for details and a fix for
the first overflow bug.
37965 seconds is a little larger than 305221 seconds. The difference might
be due to the other 70000+ seconds being in ru_stime.
The behaviour when overflow occurs is undefined, but stopping on a value
is quite likely to occur due to the algorithm for updating ru_*time.
Integer overflow tends to cause counters to reset to 0 (or INT_MIN),
but the kernel enforces monotonicity of the usage times, so they will
stick instead of going backwards to 0.
Bruce
On Thu, 17 Mar 2005, Jakub Kruszona-Zawadzki wrote: >> Description: > When a process is running for a long time (several days) time counter per process stops on value: > ru_utime.tv_sec:305221 > ru_utime.tv_usec:322735 This may be the same bug as in PR 76972. Overflow occurs at about 48592008 ticks = 379625 seconds = 105 hours for a a process that consumes 100% of the CPU if the statclock frequency is 128 Hz (which is the default and not easy to change). There is another overflow bug at 2^32 ticks = 388 days. This one is harder to fix. See PR 76972 for details and a fix for the first overflow bug. 37965 seconds is a little larger than 305221 seconds. The difference might be due to the other 70000+ seconds being in ru_stime. The behaviour when overflow occurs is undefined, but stopping on a value is quite likely to occur due to the algorithm for updating ru_*time. Integer overflow tends to cause counters to reset to 0 (or INT_MIN), but the kernel enforces monotonicity of the usage times, so they will stick instead of going backwards to 0. Bruce _______________________________________________ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscribe@freebsd.org" |