top command show impossible TIME

[gilado]

Output of top sorted by TIME.  Notice the three top processes show cumulative cpu usage of 1192h, over 49 days, for a machine whose uptime is less than 6 days (dual core machine)

Code: [Select]

top - 14:38:25 up 5 days, 11:13, 15 users,  load average: 0.42, 0.47, 0.31
Tasks: 172 total,   1 running, 171 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.0%us,  0.0%sy,  0.0%ni, 97.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   2005524k total,  1858396k used,   147128k free,   186988k buffers
Swap:  4088504k total,     1704k used,  4086800k free,   611516k cached

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+    TIME COMMAND     
17947 user       1   0  2480 1032  648 S    0  0.1  71572:19  1192h mbedit     
18532 ntp        1   0  3672 1264 1036 S    0  0.1  71571:55  1192h ntpd       
18466 root       1   0  5048  376  212 S    0  0.0  71571:55  1192h gpg-agent   



[Rudge]

If you dived 119 by 24 you get 4.9.

Perhaps there is a decimal point missing.  

[muungwana]

"man top" gives,among other entries:

TIME  --  CPU Time
          Total CPU time the task has used since it started.  When 'Cumulative mode' is On, each process is listed with the cpu time  that
          it  and  its  dead  children has used.  You toggle 'Cumulative mode' with 'S', which is a command-line option and an interactive
          command.  See the 'S' interactive command for additional information regarding this mode.

With the above,i would assume a process with many forks() will get a number larger than expected since its fork()ed processes CPU time will be added to the process time.

[Rudge]

"man top" gives,among other entries:

TIME  --  CPU Time
          Total CPU time the task has used since it started.  When 'Cumulative mode' is On, each process is listed with the cpu time  that
          it  and  its  dead  children has used.  You toggle 'Cumulative mode' with 'S', which is a command-line option and an interactive
          command.  See the 'S' interactive command for additional information regarding this mode.

With the above,i would assume a process with many forks() will get a number larger than expected since its fork()ed processes CPU time will be added to the process time.

So if processA forks 4 other processes immediately at startup and runs for 1 hour, the time for processA will read 5h.

Is that the way you are looking at it?   

[muungwana]

"man top" gives,among other entries:

TIME  --  CPU Time
          Total CPU time the task has used since it started.  When 'Cumulative mode' is On, each process is listed with the cpu time  that
          it  and  its  dead  children has used.  You toggle 'Cumulative mode' with 'S', which is a command-line option and an interactive
          command.  See the 'S' interactive command for additional information regarding this mode.

With the above,i would assume a process with many forks() will get a number larger than expected since its fork()ed processes CPU time will be added to the process time.

So if processA forks 4 other processes immediately at startup and runs for 1 hour, the time for processA will read 5h.

Is that the way you are looking at it?  

looking at it simplistically,yes but I think the proper wording should be "if the process had 1 hour of CPU time" and "not simply a process that was running for 1 hour"

If a process had 1hour of CPU time then it will be reported as taking 1 hour of CPU time.If it had 2 forked processes and each took 1 hour of CPU time,then the total CPU time reported against the parent process will be 3 CPU timehours.

How close "CPU time" and process uptime time will depend on how demanding the process is of CPU time and how much load the CPU is under.

[Rudge]

"man top" gives,among other entries:

TIME  --  CPU Time
          Total CPU time the task has used since it started.  When 'Cumulative mode' is On, each process is listed with the cpu time  that
          it  and  its  dead  children has used.  You toggle 'Cumulative mode' with 'S', which is a command-line option and an interactive
          command.  See the 'S' interactive command for additional information regarding this mode.

With the above,i would assume a process with many forks() will get a number larger than expected since its fork()ed processes CPU time will be added to the process time.

So if processA forks 4 other processes immediately at startup and runs for 1 hour, the time for processA will read 5h.

Is that the way you are looking at it?  

looking at it simplistically,yes but I think the proper wording should be "if the process had 1 hour of CPU time" and "not simply a process that was running for 1 hour"

If a process had 1hour of CPU time then it will be reported as taking 1 hour of CPU time.If it had 2 forked processes and each took 1 hour of CPU time,then the total CPU time reported against the parent process will be 3 CPU timehours.

How close "CPU time" and process uptime time will depend on how demanding the process is of CPU time and how much load the CPU is under.

So a process that has been running for 6 hours, could only have 1 hour of "cpu" time, If said process has 5 hours of "idle" time.

I see.

[gilado]

Rudge, look again it is 1192h divided by 24 yields 49 days

muungwana, cumulative time is Off. Also at least two of these processes never fork.

[gseaman]

I don't know if this is related, but there is a time accounting bug in bfs that is fixed in a new version. I don't think it affects everyone. Are you using a bfs kernel?

Galen

[gilado]

Linux odinak4 3.2.18-pclos2.bfs

Are you referring to this http://comments.gmane.org/gmane.linux.kernel/1310506

I don't have the symptoms, my uptime command show a non zero load average

$ uptime
20:35:24 up 5 days, 17:09, 13 users,  load average: 0.37, 0.54, 0.37

[gilado]

Notice in my original posting 3 processes reported that huge TIME value: ntpd gpg-agent and mbedit

While gpg-agent and ntpd have been running since boot, mbedit is a text editor i use to edit code files. 

Everything I'd start it it would immediately show up in top with an impossible TIME value. I checked that no other copies of it were running.

Anyway, I rebooted the machine, and now no process has a huge TIME value. Now when I start mbedit it does not show up with a huge value.

So reboot cleared the problem, but why it happened, why only these three processes (perhaps hey use some common code or feature) I don't know.

One more thing that seems related. Searching in an open text file in mbedit is very fast. However, when I had this problem searching for text (that exists in the file) in a small file (9Kbytes) took multiple seconds. At that time system load monitor (and top) showed half the time spent in "system"

After reboot that problem is gone too.