Re: [take28-resend_1-0 0/8] kevent: Generic event handling mechanism.
On Thu, Dec 21, 2006 at 12:14:17PM +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=projectsitem=kevent Documentation page: http://linux-net.osdl.org/index.php/Kevent Consider for inclusion. Due to this stall kevent inclusion into lighttpd CVS tree is postponed. The last version will be released saturday or sunday, and looking into overhelming flow of feedback comments on this feature, project will not be released to linux-kernel@, after this I will complete netchannels support and start kevent based AIO project - mostly network AIO with new design, which is based on set of entities, which can describe set of tasks which should be performed asynchronously (from user point of view, although read and write obviously must be done after open and before close), for example syscall which gets as parameter destination socket and local filename (with optional offset and length fields), which will asynchronously from user point of view open a file and transfer requested part to the destination socket and then return opened file descriptor (or it can be closed if requested). Similar mechanism can be done for read/write calls. Interested parties will be able to apply patches for theirs own kernels. -- 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: [take28-resend_1-0 0/8] kevent: Generic event handling mechanism.
Evgeniy Polyakov wrote: On Thu, Dec 21, 2006 at 12:14:17PM +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=projectsitem=kevent Documentation page: http://linux-net.osdl.org/index.php/Kevent Consider for inclusion. Due to this stall kevent inclusion into lighttpd CVS tree is postponed. The last version will be released saturday or sunday, and looking into overhelming flow of feedback comments on this feature, project will not be released to linux-kernel@, after this I will complete netchannels support and start kevent based AIO project - mostly network AIO with new design, which is based on set of entities, which can describe set of tasks which should be performed asynchronously (from user point of view, although read and write obviously must be done after open and before close), for example syscall kevent is being considered for inclusion, but there is no need to get impatient. Once kevent code stops getting revised rapidly, Andrew Morton can pick it up for -mm, for wide dissemination, testing and review. After that phase, it can be pushed to mainline. The feeling I get from other kernel hackers is that you are demanding inclusion now! now! now! rather than giving all stakeholders a chance to give input, and let your design sink into the collective brain. This isn't just an optional feature but a key new addition to the kernel. So we should intentionally take more time and consideration than normal. We don't want to go back and have to change fundamental kevent details due to design flaws, we want to get it right. Jeff - 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: [take28-resend_1-0 0/8] kevent: Generic event handling mechanism.
On Thu, Dec 21, 2006 at 05:41:41AM -0500, Jeff Garzik ([EMAIL PROTECTED]) wrote: Evgeniy Polyakov wrote: On Thu, Dec 21, 2006 at 12:14:17PM +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=projectsitem=kevent Documentation page: http://linux-net.osdl.org/index.php/Kevent Consider for inclusion. Due to this stall kevent inclusion into lighttpd CVS tree is postponed. The last version will be released saturday or sunday, and looking into overhelming flow of feedback comments on this feature, project will not be released to linux-kernel@, after this I will complete netchannels support and start kevent based AIO project - mostly network AIO with new design, which is based on set of entities, which can describe set of tasks which should be performed asynchronously (from user point of view, although read and write obviously must be done after open and before close), for example syscall kevent is being considered for inclusion, but there is no need to get impatient. Once kevent code stops getting revised rapidly, Andrew Morton can pick it up for -mm, for wide dissemination, testing and review. After that phase, it can be pushed to mainline. I do not say 'hey, include it now, or I will cry', I just want to have _some_ progress. But I do not get _any_ feedback. What should I think? I doubt bothering people each third day with new resend is a good idea, so I plan to drop it. Btw, Andrew dropped 'take23' patchset from his tree, when it was obsoleted, but did not import later versions :) The feeling I get from other kernel hackers is that you are demanding inclusion now! now! now! rather than giving all stakeholders a chance to give input, and let your design sink into the collective brain. No. I do not want immediate inclusion, I want progress, so I could setup my plans on it - if people keep silence, I stop this and work on my own kevent goals, since I like current state of hte kevent for my tasks. I do not hack for inclusion. This isn't just an optional feature but a key new addition to the kernel. So we should intentionally take more time and consideration than normal. We don't want to go back and have to change fundamental kevent details due to design flaws, we want to get it right. So comment on its bugs, its design, implementation, ask questions, request features, show interest (even with 'I have no time right now, but will loko at it after in a week after vacations'). No one does it, so no one cares, so my behaviour. Jeff -- 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: [take28-resend_1-0 0/8] kevent: Generic event handling mechanism.
On Thu, Dec 21, 2006 at 01:49:18PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED]) wrote: So comment on its bugs, its design, implementation, ask questions, request features, show interest (even with 'I have no time right now, but will loko at it after in a week after vacations'). No one does it, so no one cares, so my behaviour. Btw, kevent will celebrate its first birtday (one year!) in two weeks (Jan 6). Feel free to party! -- 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: [take28-resend_1-0 0/8] kevent: Generic event handling mechanism.
Evgeniy, On Thu, 2006-21-12 at 13:49 +0300, Evgeniy Polyakov wrote: So comment on its bugs, its design, implementation, ask questions, request features, show interest (even with 'I have no time right now, but will loko at it after in a week after vacations'). No one does it, so no one cares, so my behaviour. Please dont be discouraged by lack of attention - you are doing good work. I will concur with Jeff's point that since you are putting out a profound conceptual changes, and there are many stake holders, it requires scrutiny on their part. You need to build consensus in such a situation. Some things that would help progress and build momentum: - As i have advised you before, why dont you modify something like existing libraries such as some of the loop thingies of desktop managers such as kde/gnome or better things like libevent etc. Then write your app on top of that? nobody is gonna run your httpd but if you demonstrate that libevent is much better with your changes (with zero changes to apps), people will migrate - from a user space angle if people like Ulrich would state their views on the current version you have. Note, they dont have to agree with you i.e the conclusion could be a simple agree to disagree. - There really oughta be a limit on how long people are allowed to be silent. After that IMO your code should just go in ... cheers, jamal - 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: [take28-resend_1-0 0/8] kevent: Generic event handling mechanism.
On Thu, Dec 21, 2006 at 08:48:05AM -0500, jamal ([EMAIL PROTECTED]) wrote: Evgeniy, On Thu, 2006-21-12 at 13:49 +0300, Evgeniy Polyakov wrote: So comment on its bugs, its design, implementation, ask questions, request features, show interest (even with 'I have no time right now, but will loko at it after in a week after vacations'). No one does it, so no one cares, so my behaviour. Please dont be discouraged by lack of attention - you are doing good work. I will concur with Jeff's point that since you are putting out a profound conceptual changes, and there are many stake holders, it requires scrutiny on their part. You need to build consensus in such a situation. Some things that would help progress and build momentum: - As i have advised you before, why dont you modify something like existing libraries such as some of the loop thingies of desktop managers such as kde/gnome or better things like libevent etc. Then write your app on top of that? nobody is gonna run your httpd but if you demonstrate that libevent is much better with your changes (with zero changes to apps), people will migrate - from a user space angle if people like Ulrich would state their views on the current version you have. Note, they dont have to agree with you i.e the conclusion could be a simple agree to disagree. - There really oughta be a limit on how long people are allowed to be silent. After that IMO your code should just go in ... I modified world-wide used web server lighttpd and ran a lot of tests with it (compared to epoll version with major performance win). I was asked yesterday by Jan Kneschke (lighttpd main developer) if kevent API is ready so he could include my patch into mainline lighttpd tree, but I answered 'I do not know if kevent will be or not included, everyone keeps silence'. I just do not know _what_ else should be done not even for inclusion - but at least for some progress. You want libevent to be patched? Its site is currently down, but ok, I will create a patch. cheers, jamal -- 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: [take28-resend_1-0 0/8] kevent: Generic event handling mechanism.
On Thu, 2006-21-12 at 17:04 +0300, Evgeniy Polyakov wrote: I modified world-wide used web server lighttpd and ran a lot of tests with it (compared to epoll version with major performance win). I was asked yesterday by Jan Kneschke (lighttpd main developer) if kevent API is ready so he could include my patch into mainline lighttpd tree, but I answered 'I do not know if kevent will be or not included, everyone keeps silence'. Ok, so you are building the momentum then. People like Jan are the users of such API and should be speaking up. Then kernel people will be forced to look at it. I just do not know _what_ else should be done not even for inclusion - but at least for some progress. I know you are frustrated but stop doing the above like a broken vinyl record, it doesnt help your case. You want libevent to be patched? Its site is currently down, but ok, I will create a patch. I promise in 2 weeks to migrate an app or two that i have that use libevent to your version if you have it by then. I will then test and give you my opinion. cheers, jamal - 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: [take28-resend_1-0 0/8] kevent: Generic event handling mechanism.
On Thu, Dec 21, 2006 at 09:21:07AM -0500, jamal ([EMAIL PROTECTED]) wrote: I just do not know _what_ else should be done not even for inclusion - but at least for some progress. I know you are frustrated but stop doing the above like a broken vinyl record, it doesnt help your case. That's why I'm going to stop void resending completely. You want libevent to be patched? Its site is currently down, but ok, I will create a patch. I promise in 2 weeks to migrate an app or two that i have that use libevent to your version if you have it by then. I will then test and give you my opinion. Ok, when site will be ready I will patch libevent and post patch or link in this thread. I plan to complete it this week. cheers, jamal -- 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: [take28-resend_1-0 0/8] kevent: Generic event handling mechanism.
On Thu, Dec 21, 2006 at 05:23:37PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED]) wrote: Ok, when site will be ready I will patch libevent and post patch or link in this thread. I plan to complete it this week. Btw, it uses only read/write/signal on fd events, so it must use -poll() and thus be as fast as epoll. Things like sockets/pipes can only benefit from direct kevent usage instead of -poll() and wrappers. -- 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: [take28-resend_1-0 0/8] kevent: Generic event handling mechanism.
On Thu, 2006-21-12 at 17:36 +0300, Evgeniy Polyakov wrote: Btw, it uses only read/write/signal on fd events, so it must use -poll() and thus be as fast as epoll. It is supposed to detect the best mechanism in the kernel and switch to that. At the moment for example in my app it defaults to epoll. Things like sockets/pipes can only benefit from direct kevent usage instead of -poll() and wrappers. You should be able change it to use those schemes when it detects that the kernel supports them. cheers, jamal - 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: [take28-resend_1-0 0/8] kevent: Generic event handling mechanism.
On Thu, Dec 21, 2006 at 09:40:26AM -0500, jamal ([EMAIL PROTECTED]) wrote: Things like sockets/pipes can only benefit from direct kevent usage instead of -poll() and wrappers. You should be able change it to use those schemes when it detects that the kernel supports them. I.e. stat() for each new file descriptor - note, that _you_ asked it :) cheers, jamal -- 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: [take28-resend_1-0 0/8] kevent: Generic event handling mechanism.
On Thu, 2006-21-12 at 17:46 +0300, Evgeniy Polyakov wrote: On Thu, Dec 21, 2006 at 09:40:26AM -0500, jamal ([EMAIL PROTECTED]) wrote: Things like sockets/pipes can only benefit from direct kevent usage instead of -poll() and wrappers. You should be able change it to use those schemes when it detects that the kernel supports them. I.e. stat() for each new file descriptor - note, that _you_ asked it :) Didnt follow. Is there some issue with libevent you mean? cheers, jamal - 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: [take28-resend_1-0 0/8] kevent: Generic event handling mechanism.
On Thu, Dec 21, 2006 at 11:42:04AM -0500, jamal ([EMAIL PROTECTED]) wrote: Things like sockets/pipes can only benefit from direct kevent usage instead of -poll() and wrappers. You should be able change it to use those schemes when it detects that the kernel supports them. I.e. stat() for each new file descriptor - note, that _you_ asked it :) Didnt follow. Is there some issue with libevent you mean? libevent provides file descriptor without any additional info about it - so when it is added into the waiting subsystem, userspace must select different usage cases (i.e. different kevent notifications for different types of file descriptor - socket notifications for sockets and pipes, poll/select for all others), this requires stat() call per provided file descriptor. Event addition/waiting itself is the same - only parameters (type and requested event) are changed. cheers, jamal -- 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
