Re: [take29 0/8] kevent: Generic event handling mechanism.

[Ingo Molnar <mingo@elte.hu>]

* Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:

> On Thu, Dec 28, 2006 at 05:01:37PM +0100, Ingo Molnar (mingo@elte.hu) wrote:
> > 
> > * Evgeniy Polyakov <johnpol@2ka.mipt.ru> 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.

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

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

	Ingo