Re: [RFC][PATCH] iowait statistics

[Andrew Morton <akpm@zip.com.au>]

Rik van Riel wrote:
> 
> Hi,
> 
> the following patch implements iowait statistics in a simple way:
> 
> 1) if we go to sleep while waiting on a page or buffer, we
>    increment nr_iowait_tasks, note that this is done only in
>    the slow path so overhead shouldn't even be measurable
> 
> 2) if no process is running, the timer interrupt adds a jiffy
>    to the iowait time
> 
> 3) iowait time is counted separately from user/system/idle and
>    can overlap with either system or idle (when no process is
>    running the system can still be busy processing interrupts)
> 
> 4) on SMP systems the iowait time can be overestimated, no big
>    deal IMHO but cheap suggestions for improvement are welcome

I suspect that a number of these statistical accounting mechanisms
are going to break.  The new irq-affinity code works awfully well.

The kernel profiler in 2.5 doesn't work very well at present.
When investigating this, I ran a busy-wait process.  It attached
itself to CPU #3 and that CPU received precisely zero interrupts
across a five minute period.  So the profiler cunningly avoids profiling
busy CPUs, which is rather counter-productive.  Fortunate that oprofile
uses NMI.

> ...
> ===== fs/buffer.c 1.64 vs edited =====
> --- 1.64/fs/buffer.c    Mon May 13 19:04:59 2002
> +++ edited/fs/buffer.c  Mon May 13 19:16:57 2002
> @@ -156,8 +156,10 @@
>         get_bh(bh);
>         add_wait_queue(&bh->b_wait, &wait);
>         do {
> +               atomic_inc(&nr_iowait_tasks);
>                 run_task_queue(&tq_disk);
>                 set_task_state(tsk, TASK_UNINTERRUPTIBLE);
> +               atomic_dec(&nr_iowait_tasks);
>                 if (!buffer_locked(bh))
>                         break;
>                 schedule();

Shouldn't the atomic_inc cover the schedule()?


-