Alan Cox wrote: > > > fact glibc 2.2 has full aio using threads) - you have a whole frame to get > > > around to the next one plus any internal buffering > > > > Sure, and you can get around lack of select() support with threads too. But > > it's not very convenient or efficient. > > What makes you think aio is differently efficient in kernel or user space ? > In fact the original aio reference implementors took it out of kernel to user > because they found it made no difference For a number of reasons: - IO thread creation and scheduling overhead (could be a lot of them) - IO thread list processing overhead (driver/controller can maybe do better) - IO thread to app thread context switch overhead - IO thread one-at-a-time read/write prevents SCSI TCQ (or other controller) optimization Plus probably other low level kernel stuff I don't know about ;-) Ben
