Re: Asynch I/O broken in 2.2.15

From: Steve Dodd (steved@loth.demon.co.uk)
Date: Thu Apr 13 2000 - 13:24:49 EST


On Thu, Apr 13, 2000 at 09:51:24AM -0600, Jeff V. Merkey wrote:

> Yes. but you have to hold the kernel lock over the entire IO operation
> on SMP systems, including the callback or 2.2.15 crashes, which means
> you have to pass a bunch of buffer heads for each instance you hold the
> kernel lock and hold the lock until the I/O completes. This blocks all
> callers above you -- this is not very parallel or asynchronous.

OK, I'm going to ignore this bit on the grounds that I'm not very clear on
the kernel lock issues -- maybe someone else (sct?) will know about this.

> > I don't think wait_on_buffer polls anything; it starts any pending I/O
> > and then sleeps; the b_end_io callback wakes it up when the I/O is finished.
> > The only thing I'm not clear on is the purpose of the do / while loop -
> > under what situations would it get woken up without the I/O having
> > completed?

> It calls schedule() like a demon from hell in a "polling loop" while it
> sucks up processor cycles calling run_task_queue(&tq_disk) repeatedly.
> go look at the code -- buffer.c line 133.

I did. The whole point of schedule is it puts the current process to sleep -
and it /shouldn't/ get woken up again until the I/O completes. The fact that
there's a do .. while loop around that bit suggests to me that perhaps I don't
know the whole story, or perhaps someone was paranoid..

-- 
No good deed goes unpunished.

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:22 EST