| |||||||||||
Interest in asynchronous I/OInterest in asynchronous I/OPosted Jul 23, 2003 23:02 UTC (Wed) by larryr (guest, #4030)Parent article: 2003 Kernel Summit: Asynchronous I/O
I have always been mystified by the idea that there is little demand for AIO, or that it needs to prove its merit with benchmarks. To me it seems like it provides a fundamental capability to be utilized directly by applications as integral to their implementation, and to some extent even their design. It is supported by FreeBSD, Solaris, NT, etc. Oddly enough, around the time 2.5 started, Linus said "I think it's clear that many people do want to have aio support.", and "Done right, it becomes a very natural way of doing event handling, and it could very well be rather useful for many things that use select loops right now." I guess I should accept that AIO support in 2.6 is going to be weak; I just hope it is good enough to create a demand for dramatic improvements in 2.8...Larry
(Log in to post comments)
Interest in asynchronous I/O Posted Jul 25, 2003 17:11 UTC (Fri) by GreyWizard (subscriber, #1026) [Link] Could you (or someone else) explain in more technical detail what the benefit of asynchronous I/O is? Why is it better than a select(2) loop?
Interest in asynchronous I/O Posted Jul 31, 2003 12:52 UTC (Thu) by mwilck (guest, #1966) [Link] The asynchronous IO programming paradigm is more intuitive. No select loop needed. You just launch a number of AIO requests, do whatever else you want, and if you need the data you wait for the AIO completion. Moreover, between the aio submission and its completion the associated buffers belong to the kernel. That is why 0-copy basically only works this way.
Interest in asynchronous I/O Posted Jul 31, 2003 16:39 UTC (Thu) by johnchx (guest, #4262) [Link] One problem with select() is that it scales poorly to very large numbers of file descriptors. It works fine with a couple of dozen, but when you're handling 10,000 + network connections, the work of simply passing the file descriptors to and from the system call and the work (when select() returns) of figuring out which of the 10,000 descriptors has become ready can consume a significant fraction of the available cpu cycles.There's a paper on this at: http://citeseer.nj.nec.com/cache/papers/.../banga99scalable.pdf
Interest in asynchronous I/O Posted Nov 26, 2003 10:09 UTC (Wed) by yzhuang (guest, #3178) [Link] epoll has broken the bottleneck very well. it is much more scalible
|
|||||||||||