| |||||||||||
A retry-based AIO infrastructureA retry-based AIO infrastructurePosted Mar 8, 2004 13:55 UTC (Mon) by mwilck (guest, #1966)Parent article: A retry-based AIO infrastructure
It does mean, however, that work can only proceed on a single AIO request at a time. Hmm... and I thought the point of AIO was to be able to just fire off dozens of IO requests and not bother until some of them signal completion. What am I missing here?
(Log in to post comments)
One at a time Posted Mar 8, 2004 15:01 UTC (Mon) by corbet (editor, #1) [Link] Perhaps I didn't express that quite as well as I could have. What it means is that the kernel can be actively working on only one request per process at a time. There can be several requests with I/O outstanding, but, once the CPU's attention is required, only one at a time can be worked on, even on multiprocessor systems.
One at a time Posted Mar 8, 2004 20:23 UTC (Mon) by mwilck (guest, #1966) [Link] I figured that. Yet the term "asynchronous" suggests to me that the requests should be progressing independently - not the kind of serialized behavior that you describe. What if that current request is progressing slowly (think a floppy) and others in the queue never get worked on until it's completed?My impression is that it should have been the other way around: instead of implementing AIO on top of buffered IO, asynchronous requests should be the basic IO primitive and all other IO should be implemented on top of that. I can't oversee what that'd imply for the page cache, though.
One at a time Posted Mar 9, 2004 8:08 UTC (Tue) by larryr (guest, #4030) [Link] I think the thread that is handling accessing a floppy is going to be asleep almost all the time, so there will be plenty of time for other threads to wake up, do some stuff, and either finish or go back to sleep themselves. Larry
AIO as replacement for mutlithreading ? Posted Mar 9, 2004 21:47 UTC (Tue) by mwilck (guest, #1966) [Link] What are you referring to as a "thread"? An AIO request? How can other AIO requests "wake up, do some stuff" if the kernel is still handling the floppy request which blocks the single AIO entry for the process?Guess I must read the code myself. I may have put my concern in the wrong words though. One idea I have about AIO is that you can have an application behave like a multithreaded application with a singe thread. Instead of creating threads for certain IO tasks you just fire off AIO requests and they _proceed simultaneously_, as if they were driven by different threads. I wonder how that'd be possible with the serialized approach described here. Perhaps the whole notion is wrong, though?
AIO as replacement for mutlithreading ? Posted Mar 11, 2004 17:34 UTC (Thu) by larryr (guest, #4030) [Link] How can other AIO requests "wake up, do some stuff" if the kernel is still handling the floppy request which blocks the single AIO entry for the process? Most of the (wall clock) time the kernel is handling the floppy request is going to be spent sleeping (waiting for the floppy device), and while that request is sleeping another request can proceed until it either completes or has to wait for a device (sleep). Larry
One at a time Posted Apr 29, 2004 11:29 UTC (Thu) by suparna (subscriber, #7766) [Link] I'm not sure I read this correctly, but I don't think we have that kind of a limitation in the code. A workqueue thread's tsk->io_wait pointer is set to the address of the ki_wait field inside the iocb that it is handling at that particular time. There is no reason why a worker thread on another CPU cannot process another iocb, by setting its own tsk->io_wait pointer to point to another iocb's ki_wait. The point to notice here is that in these situations "tsk" refers to the task which is processing the iocb at a given time (not the task which originally issued the IO), and the io_wait pointer reflects the wait context of the iocb on whose behalf, so to say, the code is being executed.That said, it may sometimes be more efficient not to have worker threads on multiple CPUs trying to process iocbs for the same ioctx at the same time (reduces spinlock bouncing on the ioctx lock, as observed by Chris Mason). Hope that clarifies !
|
|||||||||||