Messages in this thread |  | | | Date | Mon, 13 May 2002 19:18:34 -0700 | | From | Andrew Morton <> | | Subject | Re: [RFC][PATCH] iowait statistics |
| |
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()?
- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |