Messages in this thread | | | Date | Fri, 29 Dec 2006 16:14:53 +0300 | From | Evgeniy Polyakov <> | Subject | Re: [take29 0/8] kevent: Generic event handling mechanism. |
| |
On Fri, Dec 29, 2006 at 01:54:27PM +0100, Ingo Molnar (mingo@elte.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 linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |