On 2.6.24, top started showing 100% iowait on one CPU when a UML instance was running (but completely idle). I've traced it to this commit. Reverting it cures the problem.
Miklos commit 41d10da3717409de33d5441f2f6d8f072ab3fbb6 Author: Jeff Moyer <[EMAIL PROTECTED]> Date: Tue Oct 16 23:27:20 2007 -0700 aio: account I/O wait time properly Some months back I proposed changing the schedule() call in read_events to an io_schedule(): http://osdir.com/ml/linux.kernel.aio.general/2006-10/msg00024.html This was rejected as there are AIO operations that do not initiate disk I/O. I've had another look at the problem, and the only AIO operation that will not initiate disk I/O is IOCB_CMD_NOOP. However, this command isn't even wired up! Given that it doesn't work, and hasn't for *years*, I'm going to suggest again that we do proper I/O accounting when using AIO. Signed-off-by: Jeff Moyer <[EMAIL PROTECTED]> Acked-by: Zach Brown <[EMAIL PROTECTED]> Cc: Benjamin LaHaise <[EMAIL PROTECTED]> Cc: Suparna Bhattacharya <[EMAIL PROTECTED]> Cc: Badari Pulavarty <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> diff --git a/fs/aio.c b/fs/aio.c index ea2e198..d02f43b 100644 --- a/fs/aio.c +++ b/fs/aio.c @@ -303,7 +303,7 @@ static void wait_for_all_aios(struct kioctx *ctx) set_task_state(tsk, TASK_UNINTERRUPTIBLE); while (ctx->reqs_active) { spin_unlock_irq(&ctx->ctx_lock); - schedule(); + io_schedule(); set_task_state(tsk, TASK_UNINTERRUPTIBLE); spin_lock_irq(&ctx->ctx_lock); } @@ -323,7 +323,7 @@ ssize_t fastcall wait_on_sync_kiocb(struct kiocb *iocb) set_current_state(TASK_UNINTERRUPTIBLE); if (!iocb->ki_users) break; - schedule(); + io_schedule(); } __set_current_state(TASK_RUNNING); return iocb->ki_user_data; @@ -1170,7 +1170,7 @@ retry: ret = 0; if (to.timed_out) /* Only check after read evt */ break; - schedule(); + io_schedule(); if (signal_pending(tsk)) { ret = -EINTR; break; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/