Re: Is there a current known getrusage() problem (amd64)

[Robert Elz <kre%munnari.OZ.AU@localhost>]

Oh - I meant to add, then forgot - the reason why the rusage() starts
out looking OK, and then fails, is because of the way it is computed.

As Michael van Elst said, the actual time cosumed by the process is
accurately measured.   The time spent in its various modes is sampled
(if a clock interrupt (1/hz) fires in user mode, a user mode tick is added,
if in kernel mode, a system time tick is counted, and if in an interrupt,
an interrupt time tick is added.)

Before the first tick happens, time is still accumulated - but the rusage
code has no idea whether it was user/system/interrupt time, so it
simply splits 50/50 (half is assumed to be user, and half system).

Once the first tick happens, the times are divided according to the
ratio of the number of ticks.   This is how the up/down/... that Michael
descriibed can happen - initially time is 50/50, then the first tick happens
in either user or system mode, and now we have 100/0 one way or the
other - so one of them doubled, the other went to zero.  As more ticks
happen, things tend to get more rational, and for any process that has
lasted a suitable number of ticks, the division of the time it has
accumulated should be about right.

Because of the XEN USERMODE() issue from the earlier reply, all the
ticks are being counted as system ticks, none at all as user mode.
So, until the first tick happens (somewhere between 0 and 10ms after the
process starts) we see both user and system time, and they will appear
equal (cgdconfig never looks at system time, so I did not notice this.)
Once that first tick happens, since it will always be a system time tick
(currently, on XEN) all of the CPU time consumed is counted as system
time, and user time is locked at 0.

Note that cgdconfig would care about none of these issues - it spends
all its time in user mode, ticks will be (should be) counted as user mode
ticks, almost exclusively, and eventually enough cpu time will be assumulated
that the user mode rusage() will be enough for its purpose (it now knows how
much work to do to use up enough, but not too much, CPU time) - which I
assume then gets used later when it actually encrypts something.

kre