Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
From: Zach Brown
Date: Thu Feb 22 2007 - 16:25:47 EST
Plus there's the fundamental killer that KAIO is a /lot/ harder to
implement (and to maintain) on the kernel side: it has to be
for every IO discipline, and even for the IO disciplines it
the moment, it is not truly asynchronous for things like metadata
blocking or VFS blocking. To handle things like metadata blocking
to resort to non-statemachine techniques like retries - which are bad
Yes, yes, yes.
As one of the poor suckers who has been fixing bugs in fs/aio.c and
fs/direct-io.c, I really want everyone to read Ingo's paragraph a few
times. Have it printed on a t-shirt.
Look at the number of man-years that have gone into fs/aio.c and fs/
direct-io.c. After all that effort it *barely* supports non-blocking
The maintenance overhead of those two files, above all else, is what
pushed me to finally try that nutty fibril attempt.
Syslets/threadlets on the other hand, once the core is implemented,
near zero ongoing maintainance cost (compared to KAIO pushed into
IO subsystem) and cover all IO disciplines and API variants
and they are as perfectly asynchronous as it gets.
As an experiment, I'm working on backing the sys_io_*() calls with
syslets. It's looking very promising so far.
So all in one, i used to think that AIO state-machines have a long-
place within the kernel, but with syslets i think i've proven myself
embarrasingly wrong =B-)
Welcome to the party :).
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/