BTW, there's a bug in my code -- min() should be max(), I think....
At Sun, 6 Nov 2011 14:26:02 +0000 (UTC), mlelstv%serpens.de@localhost (Michael
van Elst) wrote:
Subject: Re: getrusage() problems with user vs. system time reporting
>
> woods%planix.ca@localhost ("Greg A. Woods") writes:
>
> >I tried using hardclock_ticks in sys/syscall_stats.h, but even with
> >HZ=1000, the resolution was too fine compared to the time taken by the
> >some system calls, and even the average time slice for user mode.
> >It is _way_ better than statclock ticks though, and "almost" free.
>
> Isn't statclock there to have measurements that are _not_ synchronized
> with hardclock?
Yes, sort of.
If statistical sampling of the program counter is being done by the
clock interrupt(s) (i.e. SYSCALL_* options are not enabled), then yes
definitely. Using hardclock() alone can allow a process to accidentally
or purposefully become synchronised to the system clock leading to
either inaccurate resource utilisation or even deliberate resource
hiding. Note that on i386 so far as I can tell stathz is always zero so
hardclock() is always used to collect usage samples anyway.
With SYSCALL_* and using hardclock_ticks as the timer, I'm not sure.
Perhaps an evil process could call a cheap system call such as getpid()
just before a hardclock_tick would be incremented, which would
potentially give it an extra tick of user-mode CPU time.
That's why I would like to use a higher-resolution timer with SYSCALL_*
Using the CPU time-stamp counter is much higher resolution of course,
and in theory with it then it would be impossible for any process to
avoid resource usage detection. However since the timer is so fast that
I am forced to somehow divide that counter down to a reasonable rate
such that the calculations using it don't overflow, there may still be
room for problems.
It's really too bad that the timecounter infrastructure seems only
geared to providing one timer and there's no easy/obvious way (that I
can see) for any other kernel subsystem to reach in and access any other
potentially usable monotonic timer in a more machine independent way
(but without having to use all of binuptime() or similar). Obviously I
could do this in a platform specific way where possible, but....
With a true monotonic timer, one that gives known units of time, then
the SYSCALL_* feature could account for the actual time used in each
mode, using context switches to mark the divisions instead of having to
do any statistical sampling, and instead of having to use some timer
with an unknown rate (such as the CPU TSC) as a ticker that's then used
to divide out p_rtime between system, user, and interrupt time.
I wonder if I could get by using the frequency discovered by the
timecounter code for the CPU TSC and then from that calculate an
estimate for the amount of real time spent in each mode? The issues
with CPU timestamp counters would still remain, but perhaps that's
better than trying to use only some bits of the TSC sums.
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 250 762-7675 http://www.planix.com/
Attachment:
pgpfRcnhLiLDi.pgp
Description: PGP signature