Date: Sun, 16 Feb 2003 14:48:27 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: FreeBSD current users <current@FreeBSD.ORG> Subject: resource usage overflow Message-ID: <Pine.BSF.4.21.0302161436230.99373-100000@InterJet.elischer.org>
next in thread | raw e-mail | index | archive | help
In the resource usage we have teh following values calculated..
long ru_ixrss; /* integral shared memory size */
long ru_idrss; /* integral unshared data " */
long ru_isrss; /* integral unshared stack " */
in statclock() we have:
ru->ru_ixrss += pgtok(vm->vm_tsize);
ru->ru_idrss += pgtok(vm->vm_dsize);
ru->ru_isrss += pgtok(vm->vm_ssize);
in other words these ore incremented at the rate of statclock
(for example 1kHz in not unheard of now).
Assuming that I have a 600MB process (e.g. fsck doing a 1TB fileesyste
uses 667MB in pass 1 alone).
this means that the number of ticks we can count this amount of memory
usage for is:
4E9/6E5 = 7.1E3 or 7100 ticks or,
in the realworld (TM)... seven seconds if I am doing stats and profiling
at 1kHz.
I think I could make a case for these figures being extended to 64 bits
but:
1/ is it worth it? what uses them? Easier to drop them.
2/ are these mandated by any standard? would making them 64 bits
break anything?
3/ would 64 bits be enough? We are getting both bigger and faster
64000 times faster and 64000 times bigger and we are back at seven
seconds. 640 times faster and 640 times bigger and we are still only at
70000 seconds (19 hours) before overflow.
Julian
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0302161436230.99373-100000>