Messages in this thread | | | From | Zach Brown <> | Subject | Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3 | Date | Thu, 22 Feb 2007 13:23:57 -0800 |
| |
> 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.
Amen.
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |