4

Reading from /proc/PID/stat a lot of information can be processed. I would like to see how many percentages has been used of CPU power by this process. There are a lot of variable around here (utime, stime, cutime, cstime, gtime, cgtime) but they are in jiffies. The problem with this that jiffy depends on speed of the current CPU. However IPS (Instructions Per Second) depends on inctructions set, and which program do we run but maybe this is more accurete.

I would like to use this information in embedded systems where I could pick a CPU that just satisfies the features. In this way I don't have to spend a lot for a largly oversized system.

Here is the contents of the stat file (as of 2.6.30-rc7):

 Field          Content
  pid           process id
  tcomm         filename of the executable
  state         state (R is running, S is sleeping, D is sleeping in an
                uninterruptible wait, Z is zombie, T is traced or stopped)
  ppid          process id of the parent process
  pgrp          pgrp of the process
  sid           session id
  tty_nr        tty the process uses
  tty_pgrp      pgrp of the tty
  flags         task flags
  min_flt       number of minor faults
  cmin_flt      number of minor faults with child's
  maj_flt       number of major faults
  cmaj_flt      number of major faults with child's
  utime         user mode jiffies
  stime         kernel mode jiffies
  cutime        user mode jiffies with child's
  cstime        kernel mode jiffies with child's
  priority      priority level
  nice          nice level
  num_threads   number of threads
  it_real_value (obsolete, always 0)
  start_time    time the process started after system boot
  vsize         virtual memory size
  rss           resident set memory size
  rsslim        current limit in bytes on the rss
  start_code    address above which program text can run
  end_code      address below which program text can run
  start_stack   address of the start of the stack
  esp           current value of ESP
  eip           current value of EIP
  pending       bitmap of pending signals
  blocked       bitmap of blocked signals
  sigign        bitmap of ignored signals
  sigcatch      bitmap of catched signals
  wchan         address where process went to sleep
  0             (place holder)
  0             (place holder)
  exit_signal   signal to send to parent thread on exit
  task_cpu      which CPU the task is scheduled on
  rt_priority   realtime priority
  policy        scheduling policy (man sched_setscheduler)
  blkio_ticks   time spent waiting for block IO
  gtime         guest time of the task in jiffies
  cgtime        guest time of the task children in jiffies
Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175
roncsak
  • 299
  • 5
  • 12

1 Answers1

1

The jiffy does not depend on the CPU speed directly. It is a time period that is used to count different time intervals in the kernel. The length of the jiffy is selected at kernel compile time. More about this: man 7 time

One of fundamental uses of jiffies is a process scheduling. One jiffy is a period of time the scheduler will allow a process to run without an attempt to reschedule and swap the process out to let another process to run.

For slow processors it is fine to have 100 jiffies per second. But kernels for modern processors usually configured for much more jiffies per second.

roncsak
  • 299
  • 5
  • 12
Serge
  • 8,371
  • 2
  • 23
  • 28
  • Right! So 1 jiffy is 4ms by default in i386 systems. As I understand, only 1 process runs in that time. In the next jiffy an other process runs and so on. Performed instructions in that timeframe depends on cpu speed. So we could say that there is no point converting jiffies to mips because we don't know how instructions has been performed in 1 jiffy. CPU could use all the 4ms or just 1ms for calculation. Is that right ? – roncsak Oct 16 '12 at 08:44
  • @roncsak Yes, on a single core CPU without Hyper Threading at any moment only one process thread or kernel thread is running. And the rest of your statement is also correct. – Serge Oct 17 '12 at 15:34