Q:

Counting clock ticks in Linux 2.4.14

I am trying to count the total number of clock ticks for each process (only when it's actually running). I inserted the following code in schedule() (file sched.h):
...
switch_tasks:
    prefetch(next);
    clear_tsk_need_resched(prev);
    if (likely(prev != next)) {
        rq->nr_switches++;
        rq->curr = next;

        /* My code start here*/
        if (next->start_count==1)
            next->start_run=jiffies;
        if (prev->start_count==1)
        {
            prev->total_running += (jiffies-prev->start_run);
            printk("total running = %lu, jif-start = %lu\n", \
            prev->total_running, jiffies-prev->start_run);
        }
...

I added the printk because I got weird results. Here is some of the output:

total running = 1522, jif-start = 1 
  total running = 1522, jif-start = 0 
  total running = 1523, jif-start = 1 
  total running = 1, jif-start = 1 
  total running = 0, jif-start = 0 
  total running = 0, jif-start = 0 
  total running = 0, jif-start = 0 
  total running = 0, jif-start = 0 

It does not make sense to me. Is something wrong with my code?

A:

The trace output is showing per-task state, so it might make more sense if you also printed prev->pid to identify which task you're talking about.
EDIT: OK, if you're concerned about getting "jif-start = 0" : note that jiffies only increments on every timer interrupt, which I think is almost certainly every 10ms for a 2.4.14 kernel.  It's quite possible (or even likely) that your I/O-bound processes could wake up, and then block on I/O very quickly, causing another reschedule before the jiffy counter increases.
It's possible that you may be able to get higher-resolution time intervals from do_gettimeofday() (declared in<linux/time.h>) but the actual resolution you'll get out of that depends on the platform.

