* [9fans] stats.c bug
@ 2003-06-18 20:51 andrey mirtchovski
2003-06-18 20:59 ` Russ Cox
0 siblings, 1 reply; 3+ messages in thread
From: andrey mirtchovski @ 2003-06-18 20:51 UTC (permalink / raw)
To: 9fans
there is a small bug with stats.c's readnum() routine -- the numbers for
context switches, system calls and interrupts are unsigned long (I believe)
but are converted using strtol().
if a machine is left running cpu-heavy applications for a long time (say,
a week) those numbers will overflow and strtol() will return LONG_MAX as the
value. the net effect is that stats.c will not display context, syscalls and
interrupts properly.
here's a sample cat /dev/systat:
0 2530252355 3182187863 2996662559 3944850 0 0 0 99 0
0 2530252917 3182188061 2996663328 3944996 0 0 0 98 0
0 2530253045 3182188170 2996663495 3945138 0 0 0 99 0
0 2530253224 3182188295 2996663728 3945284 0 0 0 100 0
there is also a new entry (the 10th number) reported by /dev/sysstat, which
is undocumented in the man pages. in the kernel source (port/portdat.h) it
is documented as:
ulong avg_inintr; /* avg time per clock tick in interrupt handlers */
i took the liberty of modifying stats.c to include this statistic (note:
i have not modified the manpage, nor added an argument option to invoke this
from the command line -- i figured since 'idle' isn't there yet i'd better
leave this for other people to decide).
andrey
plan9% diff stats.c /sys/src/cmd/stats.c
45d44
< InIntr,
65,66c64,65
< long devsysstat[10];
< long prevsysstat[10];
---
> long devsysstat[9];
> long prevsysstat[9];
108d106
< Minintr,
129d126
< "add in intr ",
150d146
< inintrval(Machine*, long*, long*, int),
171d166
< inintrval,
434c429
< a[i] = strtoul(p, &p, 10);
---
> a[i] = strtol(p, &p, 10);
676c671
< present[Minintr] | present[Msyscall] | present[Mtlbmiss] | present[Mtlbpurge];
---
> present[Msyscall] | present[Mtlbmiss] | present[Mtlbpurge];
829,835d823
< *vmax = 100;
< }
<
< void
< inintrval(Machine *m, long *v, long *vmax, int)
< {
< *v = m->devsysstat[InIntr];
plan9%
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [9fans] stats.c bug
2003-06-18 20:51 [9fans] stats.c bug andrey mirtchovski
@ 2003-06-18 20:59 ` Russ Cox
2003-06-18 21:57 ` andrey mirtchovski
0 siblings, 1 reply; 3+ messages in thread
From: Russ Cox @ 2003-06-18 20:59 UTC (permalink / raw)
To: 9fans
> if a machine is left running cpu-heavy applications for a long time (say,
> a week) those numbers will overflow and strtol() will return LONG_MAX as the
> value. the net effect is that stats.c will not display context, syscalls and
> interrupts properly.
umm, what if i leave it running for two weeks?
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [9fans] stats.c bug
2003-06-18 20:59 ` Russ Cox
@ 2003-06-18 21:57 ` andrey mirtchovski
0 siblings, 0 replies; 3+ messages in thread
From: andrey mirtchovski @ 2003-06-18 21:57 UTC (permalink / raw)
To: 9fans
On Wed, 18 Jun 2003, Russ Cox wrote:
> umm, what if i leave it running for two weeks?
>
the numbers would wrap and there will be a single instance where stats would
report errors, afterwards it should be back to normal until the next wrap, no?
if that's not the case (i.e. if /dev/sysstat reports 'long long'-s) then we
should use strtoll()...
i don't see the catch, sorry :(
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2003-06-18 21:57 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-06-18 20:51 [9fans] stats.c bug andrey mirtchovski
2003-06-18 20:59 ` Russ Cox
2003-06-18 21:57 ` andrey mirtchovski
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).