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 implemented
for every IO discipline, and even for the IO disciplines it supports at
the moment, it is not truly asynchronous for things like metadata
blocking or VFS blocking. To handle things like metadata blocking it has
to resort to non-statemachine techniques like retries - which are bad
for performance.

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 O_DIRECT IO.

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, have
near zero ongoing maintainance cost (compared to KAIO pushed into every
IO subsystem) and cover all IO disciplines and API variants immediately,
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- term
place within the kernel, but with syslets i think i've proven myself
embarrasingly wrong =B-)

Welcome to the party :).

- z
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at