Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

Linux Storage and Filesystem workshop, day 1

Posted Apr 7, 2009 18:19 UTC (Tue) by mezcalero (subscriber, #45103)
Parent article: Linux Storage and Filesystem workshop, day 1

Could someone please enlighten me why aio should happen in kernel space at all, especially since acall() just seems to distribute work on different threads anyway? That could be done in userspace as well, and in fact is done in GLib's GVFS.

(Log in to post comments)

Posted Apr 7, 2009 20:18 UTC (Tue) by njs (guest, #40338) [Link]

In Zach's original patch set, the thread was spawned iff satisfying the IO request required blocking (so if the data was in cache, thread spawning/joining overhead was avoided), which you can't determine from userspace. Not sure how much that matters (a kernel thread is what, two pages?) or whether it's part of this version of the patch, though.

Linux Storage and Filesystem workshop, day 1

Posted Apr 8, 2009 1:33 UTC (Wed) by mezcalero (subscriber, #45103) [Link]

Hmm, not sure of programs really want to make use of that functionality. Also, wouldn't it be easier to simply allow O_NDELAY style access to files? Then blocking IO requests could simply return EAGAIN and userspace could start a thread for it, and everything could be done easily in userspace.

In addition, the POSIX aio doesn't allow such 'early' returns. (POSIX aio is an awful API anyway, with all those signals)

Using threads for AIO? Best do it in userspace.

Posted Apr 8, 2009 6:38 UTC (Wed) by xoddam (subscriber, #2322) [Link]

I agree entirely, posted words to the same effect below.