Hi,

I checked and this this seems to be the case.

I actually noticed something even a bit odder though.  Notice process 3176 
below.    Three diffferent samples, 20 secs between the first and second, 
28 between the second and third.  In all three samples 3176 not only didn't
seem to accumulate any cpu time, but, it stayed running always on
cpu 3.  The whole time it seemed to be on CPU/3 but top is a bit crude for
this.

Maybe this is just some artifict of cpu afinity in the scheduler, but,
it does seem odd.

cheers

bruce



load averages:  1.16,  0.72,  0.90                  up 0 days,  4:05   13:30:17
41 processes:  1 runnable, 36 sleeping, 4 on processor
CPU0 states: 96.1% user,  0.0% nice,  1.5% system,  2.5% interrupt,  0.0% idle
CPU1 states: 98.5% user,  0.0% nice,  1.5% system,  0.0% interrupt,  0.0% idle
CPU2 states: 99.0% user,  0.0% nice,  1.0% system,  0.0% interrupt,  0.0% idle
CPU3 states: 98.0% user,  0.0% nice,  2.0% system,  0.0% interrupt,  0.0% idle
Memory: 69M Act, 3848K Wired, 7136K Exec, 43M File, 157M Free
Swap: 200M Total, 200M Free
Seconds to delay: 
  PID USERNAME PRI NICE   SIZE   RES STATE      TIME   WCPU    CPU COMMAND
 3176 edoneel    2    0  3828K 5100K CPU/3      0:09 96.04% 48.39% ecl
 3341 edoneel   55    0  2972K 4684K CPU/1      0:13 95.94% 48.34% ecl
 2983 edoneel    2    0  3832K 5520K CPU/2      0:08 95.27% 48.00% ecl
 3731 edoneel   55    0  2972K 4684K RUN/0      0:13 95.17% 47.95% ecl
 1829 edoneel    2    0   204K 1168K CPU/0      0:48  0.93%  0.93% top

load averages:  2.04,  0.95,  0.97                  up 0 days,  4:06   13:30:37
41 processes:  1 runnable, 36 sleeping, 4 on processor
CPU0 states: 98.0% user,  0.0% nice,  1.0% system,  1.0% interrupt,  0.0% idle
CPU1 states:  100% user,  0.0% nice,  0.0% system,  0.0% interrupt,  0.0% idle
CPU2 states:  100% user,  0.0% nice,  0.0% system,  0.0% interrupt,  0.0% idle
CPU3 states:  100% user,  0.0% nice,  0.0% system,  0.0% interrupt,  0.0% idle
Memory: 82M Act, 3848K Wired, 7136K Exec, 43M File, 144M Free
Swap: 200M Total, 200M Free
Seconds to delay: 
  PID USERNAME PRI NICE   SIZE   RES STATE      TIME   WCPU    CPU COMMAND
 3341 edoneel   57    0  6636K 8280K CPU/1      0:33 98.83% 80.81% ecl
 3176 edoneel    2    0  6632K 8280K CPU/3      0:09 98.71% 80.71% ecl
 2983 edoneel   57    0  6636K 8280K CPU/2      0:32 97.87% 80.03% ecl
 3731 edoneel   57    0  6636K 8280K RUN/0      0:33 97.22% 79.49% ecl
 1829 edoneel    2    0   204K 1168K CPU/0      0:49  0.78%  0.78% top

load averages:  2.77,  1.21,  1.06                  up 0 days,  4:06   13:31:05
41 processes:  1 runnable, 36 sleeping, 4 on processor
CPU0 states: 96.6% user,  0.0% nice,  1.9% system,  1.5% interrupt,  0.0% idle
CPU1 states:  100% user,  0.0% nice,  0.0% system,  0.0% interrupt,  0.0% idle
CPU2 states:  100% user,  0.0% nice,  0.0% system,  0.0% interrupt,  0.0% idle
CPU3 states:  100% user,  0.0% nice,  0.0% system,  0.0% interrupt,  0.0% idle
Memory: 82M Act, 3848K Wired, 7136K Exec, 43M File, 144M Free
Swap: 200M Total, 200M Free
Seconds to delay: 
  PID USERNAME PRI NICE   SIZE   RES STATE      TIME   WCPU    CPU COMMAND
 3176 edoneel    2    0  6632K 8280K CPU/3      0:09 99.62% 94.92% ecl
 2983 edoneel   64    0  6636K 8280K RUN/0      1:00 99.01% 94.34% ecl
 3341 edoneel   64    0  6636K 8280K CPU/2      1:00 98.96% 94.29% ecl
 3731 edoneel   64    0  6636K 8280K CPU/1      1:00 98.44% 93.80% ecl

On Thu, Nov 10, 2005 at 08:56:33PM +0000, David Laight wrote:
> On Thu, Nov 10, 2005 at 04:19:25PM +0000, Christos Zoulas wrote:
> > 
> > Well, pp->p_rtime_sec is supposed to work but somehow in your case it doesn't.
> > I cannot really explain why it does not work, since this is a copy of:
> > 
> > 	p->p_rtime.tv_sec
> 
> Got it....
> 
> The scheduler remembers the time at which the process started running,
> when it switches out (or goes idle) it adds that elapsed time period
> to p_rtime.
> 
> In your case the processes never sleep, and only the one on cpu0 is ever
> suspended to allow another process (eg top) to run.
> 
> So top (and anything else) can only report the execution time of the
> last time the process stopped running.
> 
> Actually on a system with a TSC (even a broken one like the net4801)
> it ought to be possible to accumulate user, kernel and interrupt
> time by reading the TSC - in which case this wouldn't happen because
> the values would get summed onto the process every clock interrupt.
> 
> This scheme would also solve the 'reported cpu time goes down' bugs.
> 
> Alternatively the code that returns the values (in the bowels of sysctl)
> could add in the execution time of active processes before returning
> the data.
> 
> 	David
> 
> -- 
> David Laight: david@l8s.co.uk

-- 
edoneel@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org