On Fri, Dec 29, 2006 at 01:54:27PM +0100, Ingo Molnar ([email protected]) wrote:
> > > > Generic event handling mechanism.
> > >
> > > i see it covers alot of event sources, but i cannot see block IO
> > > notifications. Am i missing something?
> >
> > Depending on what it is :) If you mean kevent based AIO, then it was
> > dropped to reduce size of the patchset, and in favour of new AIO
> > design.
>
> yes, kevent based AIO. Could you please re-add it, preferably ontop of
> Suparna's AIO patchset? I dont see how a "generic event handling
> mechanism" can exclude block IO because we really need to see how it
> plugs into (and plays along with) block AIO and how it performs relative
> to block AIO to be able to judge whether this API and infrastructure
> should be included in the kernel in its current form.
I like new design much more than my previous kevent based approach and
existing repeated call approach. I plan to start working on it jst after
New Year vacations are over (in about a week or two, it is the longest
vacations of the year in Russia, which are spent in a way which does not
allow to hack or perform any other usefull work).
Kevent AIO was completely different thing than Suparna's AIO, and
although it hooked into block/fs subsystem on a bit different layer (I
exported ->get_block() callback), it was possible to fully separate AIO
from main code.
> > Other kinds of read/write notifications can be handled by poll/select
> > notifications.
>
> but poll/select notifications are just a second-degree way of doing an
> IO state machine, and they are mostly there in kevents for completeness
> and compatibility.
Yes, indeed.
> To be able to judge a "generic" event mechanism it really must support
> block IO as well, natively. Without that we'd have the following obscene
> API situation:
>
> - poll()/select(): supports everything but is slow and inaccurate
> - epoll(): more modern API ontop of poll notifications
> - async IO: supports block IO
Network AIO should not be different from block IO - it is essentially
the same mechanisms, which just have different lower layer from where
callbacks are invoked.
> - kevent supports almost everything /except/ block IO
>
> so what we need is for kevents to support /all/ the important
> high-performance event types natively:
>
> - networking
> - block IO
> - VFS namespace
> - timers
>
> (rarer things like mouse/input events can stay with poll notifications)
>
> and it is /especially/ important to include block IO events in kevents
> to be able to judge its performance and scalability relative to the
> async IO API and infrastructure.
Yes, async IO is a significant part, and will be implemented, IMHO, new
design I highlighted in linux-fsdevel@ in AIO related thread is the way
to go (at least I will imlement it that way).
> Ingo
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
