Date:	Fri, 29 Dec 2006 16:14:53 +0300
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	David Miller <davem@...emloft.net>,
	Ulrich Drepper <drepper@...hat.com>,
	Andrew Morton <akpm@...l.org>, netdev <netdev@...r.kernel.org>,
	Zach Brown <zach.brown@...cle.com>,
	Christoph Hellwig <hch@...radead.org>,
	Chase Venters <chase.venters@...entec.com>,
	Johann Borck <johann.borck@...sedata.com>,
	linux-kernel@...r.kernel.org, Jeff Garzik <jeff@...zik.org>,
	Jamal Hadi Salim <hadi@...erus.ca>
Subject: Re: [take29 0/8] kevent: Generic event handling mechanism.

On Fri, Dec 29, 2006 at 01:54:27PM +0100, Ingo Molnar (mingo@...e.hu) 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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists