Cc: Ingo Molnar <mingo@...>, Linus Torvalds <torvalds@...>, Ulrich Drepper <drepper@...>, <linux-kernel@...>, Arjan van de Ven <arjan@...>, Christoph Hellwig <hch@...>, Andrew Morton <akpm@...>, Alan Cox <alan@...>, Zach Brown <zach.brown@...>, David S. Miller <davem@...>, Suparna Bhattacharya <suparna@...>, Davide Libenzi <davidel@...>, Jens Axboe <jens.axboe@...>, Thomas Gleixner <tglx@...>
On Tue, Feb 27, 2007 at 06:52:22AM -0500, Theodore Tso (tytso@mit.edu) wrote:
Hi Ted.
I understand that - and I totally agree.
But when more complex, more bug-prone code results in higher performance
- that must be used. We have linked lists and binary trees - the latter
are quite complex structures, but they allow to have higher performance
in searching operatins, so we use them.
The same applies to state machines - yes, in some cases it is hard to
program, but when things are already implemented and are wrapped into
nice (no posix) aio_read(), there is absolutely no usage complexity.
Even if it is up to programmer to programm state machine based on
generated events, that higher-layer state machines are not complex.
Let's get simple case of (aio_)read() from file descriptor - if page is in the
cache, no readpage() method will be called, so we do not need to create
some kind of events - just copy data, if there is no page or page is not
uptodate, we allocate a bio and do not wait until buffers are read - we
return to userspace and start another reading, when bio is completed and
its end_io callback is called, we mark pages as uptodate, copy data to userspace,
and mark event bound to above (aio_)read() as completed.
(that is how kevent aio works, btw).
Userspace programmer just calls
cookie = aio_read();
aio_wait(cookie);
or something like that.
It is simple, it is straightforward, especially if data read must then
be used somewhere else - in that case processing thread will need to operate
with main one, which is simple in event model, since there is a place,
where events of _all_ types are gathered.
--
Evgeniy Polyakov
-
