Re: [take29 0/8] kevent: Generic event handling mechanism.
* Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > > (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). yes. Note that a prototype exists already: take a look at Tux's "work atom" infrastructure of how you can build a relatively straightforward state-machine that can be programmed and can be driven even from IRQ contexts. Via that i implemented fully asynchronous IO for networking 5 years ago, and programmed it to handle HTTP and FTP protocol server logic, fully asynchronously. (For block IO it also does emulation of event handling via the 'cachemiss' kernel threads. State-machine driven filesystems are quite hard - but not impossible in the long run.) It would be a natural thing to extend that fundamental concept to user-space as well. /That/ i'd call a generic, grounds-up event handling infrastructure. That would be a worthwile unification point for all existing IO APIs. Ingo - 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
Re: [take29 0/8] kevent: Generic event handling mechanism.
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 netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [take29 0/8] kevent: Generic event handling mechanism.
* Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > On Thu, Dec 28, 2006 at 05:01:37PM +0100, Ingo Molnar ([EMAIL PROTECTED]) > wrote: > > > > * Evgeniy Polyakov <[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. > 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 - 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
Re: [take29 0/8] kevent: Generic event handling mechanism.
On Thu, Dec 28, 2006 at 05:01:37PM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote: > > * Evgeniy Polyakov <[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. Other kinds of read/write notifications can be handled by poll/select notifications. > Ingo -- 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
Re: [take29 0/8] kevent: Generic event handling mechanism.
On Thu, Dec 28, 2006 at 04:56:45PM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote: > > * Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > > > Generic event handling mechanism. > > it would be /very/ helpful to state against which kernel tree the > patch-queue is. It does not apply to 2.6.20-rc1 nor to -rc2 nor to > 2.6.19. At which point i gave up ... It was against 2.6.18 (d4397acde6fd047f13c744e5471a9bfe287f78a3) git. Next patchset with possibility to inject already read event and userspace reserved notifications will be against the latest tree (I will push it today before final New Year celebration started). > Ingo -- 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
Re: [take29 0/8] kevent: Generic event handling mechanism.
* Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > Generic event handling mechanism. it would be /very/ helpful to state against which kernel tree the patch-queue is. It does not apply to 2.6.20-rc1 nor to -rc2 nor to 2.6.19. At which point i gave up ... Ingo - 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
Re: [take29 0/8] kevent: Generic event handling mechanism.
* Evgeniy Polyakov <[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? Ingo - 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
Re: [take29 0/8] kevent: Generic event handling mechanism.
On Sat, Dec 23, 2006 at 07:51:40PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED]) wrote: > > Generic event handling mechanism. > > Kevent is a generic subsytem which allows to handle event notifications. > It supports both level and edge triggered events. It is similar to > poll/epoll in some cases, but it is more scalable, it is faster and > allows to work with essentially eny kind of events. > > Events are provided into kernel through control syscall and can be read > back through ring buffer or using usual syscalls. > Kevent update (i.e. readiness switching) happens directly from internals > of the appropriate state machine of the underlying subsytem (like > network, filesystem, timer or any other). > > Homepage: > http://tservice.net.ru/~s0mbre/old/?section=projects&item=kevent > > Documentation page: > http://linux-net.osdl.org/index.php/Kevent > > Consider for inclusion. > > New benchmark, which can be a hoax though, can be found at > http://tservice.net.ru/~s0mbre/blog/2006/11/30#2006_11_30 > where kevent on amd64 with 1gb of ram can handle more than 7200 events per > second with 8000 requests concurrency with 'ab' benchmark and lighttpd. > Although I tought it should not be published due to possible errors, > I decided to send it for review. > > With this release I start 3 days resending timeout - i.e. each third day I > will send either new version (if something new was requested and agreed to > be implemented) or resending with back counter started from three. > When back counter hits zero after three resending I consider there is no > interest in subsystem and I will stop further sending. > First one will be sent about Jan 10. > > Thanks for understanding and your time. > > Changes from 'take28' patchset: > * optimized af_unix to use socket notifications > * changed ALWAYS_QUEUE behaviour with poll/select notifications - previously > kevent was not queued into poll wait queue when ALWAYS_QUEUE flag > is set > * added KEVENT_POLL_POLLRDHUP definition into ukevent.h header > * libevent-1.2 patch (Jamal, your request is completed, so I'm waiting two > weeks > before starting final countdown :) > All regression tests passed successfully except test_evbuffer(), which > crashes on my amd64 linux 2.6 test machine for all types of > notifications, > probably it is fixed in libevent-1.2a version, I did not check. > Patch and README can be found at project homepage. P.S. all kernel kevent options must be turned on (namely kevent_poll, kevent_socket and kevent_pipe). I did not hack 'configure' to check for supported notification types. -- 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
[take29 0/8] kevent: Generic event handling mechanism.
Generic event handling mechanism. Kevent is a generic subsytem which allows to handle event notifications. It supports both level and edge triggered events. It is similar to poll/epoll in some cases, but it is more scalable, it is faster and allows to work with essentially eny kind of events. Events are provided into kernel through control syscall and can be read back through ring buffer or using usual syscalls. Kevent update (i.e. readiness switching) happens directly from internals of the appropriate state machine of the underlying subsytem (like network, filesystem, timer or any other). Homepage: http://tservice.net.ru/~s0mbre/old/?section=projects&item=kevent Documentation page: http://linux-net.osdl.org/index.php/Kevent Consider for inclusion. New benchmark, which can be a hoax though, can be found at http://tservice.net.ru/~s0mbre/blog/2006/11/30#2006_11_30 where kevent on amd64 with 1gb of ram can handle more than 7200 events per second with 8000 requests concurrency with 'ab' benchmark and lighttpd. Although I tought it should not be published due to possible errors, I decided to send it for review. With this release I start 3 days resending timeout - i.e. each third day I will send either new version (if something new was requested and agreed to be implemented) or resending with back counter started from three. When back counter hits zero after three resending I consider there is no interest in subsystem and I will stop further sending. First one will be sent about Jan 10. Thanks for understanding and your time. Changes from 'take28' patchset: * optimized af_unix to use socket notifications * changed ALWAYS_QUEUE behaviour with poll/select notifications - previously kevent was not queued into poll wait queue when ALWAYS_QUEUE flag is set * added KEVENT_POLL_POLLRDHUP definition into ukevent.h header * libevent-1.2 patch (Jamal, your request is completed, so I'm waiting two weeks before starting final countdown :) All regression tests passed successfully except test_evbuffer(), which crashes on my amd64 linux 2.6 test machine for all types of notifications, probably it is fixed in libevent-1.2a version, I did not check. Patch and README can be found at project homepage. Changes from 'take27' patchset: * made kevent default yes in non embedded case. * added falgs to callback structures - currently used to check if kevent can be requested from kernelspace only (posix timers) or userspace (all others) Changes from 'take26' patchset: * made kevent visible in config only in case of embedded setup. * added comment about KEVENT_MAX number. * spell fix. Changes from 'take25' patchset: * use timespec as timeout parameter. * added high-resolution timer to handle absolute timeouts. * added flags to waiting and initialization syscalls. * kevent_commit() has new_uidx parameter. * kevent_wait() has old_uidx parameter, which, if not equal to u->uidx, results in immediate wakeup (usefull for the case when entries are added asynchronously from kernel (not supported for now)). * added interface to mark any event as ready. * event POSIX timers support. * return -ENOSYS if there is no registered event type. * provided file descriptor must be checked for fifo type (spotted by Eric Dumazet). * signal notifications. * documentation update. * lighttpd patch updated (the latest benchmarks with lighttpd patch can be found in blog). Changes from 'take24' patchset: * new (old (new)) ring buffer implementation with kernel and user indexes. * added initialization syscall instead of opening /dev/kevent * kevent_commit() syscall to commit ring buffer entries * changed KEVENT_REQ_WAKEUP_ONE flag to KEVENT_REQ_WAKEUP_ALL, kevent wakes only first thread always if that flag is not set * KEVENT_REQ_ALWAYS_QUEUE flag. If set, kevent will be queued into ready queue instead of copying back to userspace when kevent is ready immediately when it is added. * lighttpd patch (Hail! Although nothing really outstanding compared to epoll) Changes from 'take23' patchset: * kevent PIPE notifications * KEVENT_REQ_LAST_CHECK flag, which allows to perform last check at dequeueing time * fixed poll/select notifications (were broken due to tree manipulations) * made Documentation/kevent.txt look nice in 80-col terminal * fix for copy_to_user() failure report for the first kevent (Andrew Morton) * minor function renames Changes from 'take22' patchset: * new ring buffer implementation in process' memory * wakeup-one-thread flag * edge-triggered behaviour Changes from 'take21' patchset: * minor cleanups (different return values, removed unneded variables, whitespaces and so on) * fixed bug in kevent removal in case when kevent being removed is the same as overflow_kevent (spotted by Eric Dumazet) Changes from 'take20' patchset: * new ring buffer implementation * removed artificial limit o
