On Thu, Feb 09, 2006 at 03:55:18PM -0500, Benjamin LaHaise ([EMAIL PROTECTED])
wrote:
> On Thu, Feb 09, 2006 at 08:03:26PM +0300, Evgeniy Polyakov wrote:
> > It is completely different things.
> > The only common is that they _require_ some kind of notification
> > mechanism,
> > but none provide them.
> > epoll() can not be used for AIO and timers.
>
> True, that is a disappointment. There really should be a timer device in
> /dev which can be used with all of the possible event mechanism.
It still can not be controlled over epoll(), since epoll does not
provide _control_, it only receives event generated by device,
but it does not allow to setup source of that events.
> > AIO can not be used with anything except AIO.
>
> Actually, there are patches for generic thread based aio so that other
> file descriptors can be used for AIO, perhaps they should be dusted off?
> They're pretty small and easy to understand.
Is it SGI kaio?
> Btw, your kevent aio is not interopable with O_DIRECT AIO on files. This
> is a pretty major setback for quite a few types of high performance servers.
I leaved files alone - kevent support network aio,
but I do not see big problems to call kevent's callbacks from VFS
allocation path, so that callback could copy data to/from userspace,
actually socket notifications are bound to inode, so it is almost the
same.
> > inotify is good, but it can not be used for anything else.
>
> Now. this is funny! =-)
Actually kevent inode notification supports inode creation/deletion,
and it is very easy to several new notifications, but inotify and kevent
have completely different design:
inotify will allocate and send events until either queue is filled,
or activity is removed, but kevent will only mark _requested_ event as
ready. Both approaches have it's own pros and cons.
> > > > asynchronously from socket's receiving queue from softirq
> > > > context.
> > >
> > > Is there any reason for not using the existing aio read method?
> >
> > Current AIO has it's own design which I do not accept completely.
> > It does not use internal state machines of underlying layers, but instead
> > repeatedly tries to call nonblocking functions, similar to synchronous
> > ones.
>
> Actually, that behaviour is completely up to the implementor of the aio
> method. Retry simply happens to be a very simple technique that allows
> existing code to be easily updated to implement aio. AIO operations can
> be implemented as a state machine -- the 2.4 codebase did that for file
> io, and it worked quite well. For something like networking, it could
> well be the way to go.
AIO folks showed some performance degradation on theirs paper in several
environments.
Roots of this probably lives in latencies introduced by delayed invocation,
state machine approach implemented using kevent should not suffer from
such design.
> On the networking front, it would be very useful to have an AIO method to
> implement zero copy transmit. Most of the pieces are in place with the
> sendpage code, but the catch is that we would need a destructor to use
> with data submitted via sendpage. Are you interested in exploring a few
> more approaches to the design and tie-in with existing kernel AIO? Cheers,
Asynchronous send and sendfile are definitely in agenda, but main aim
was to implement receiving support and show design of kevent and it's
abilities to community.
This approach allows to place hooks in deep internals of existing state
machines, so it is very convenient and fast, since no work is postponed
to thread or delayed invocation.
> -ben
> --
> "Ladies and gentlemen, I'm sorry to interrupt, but the police are here
> and they've asked us to stop the party." Don't Email: <[EMAIL PROTECTED]>.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
