Re: [take26-resend1 0/8] kevent: Generic event handling mechanism.
Evgeniy Polyakov wrote: On Mon, Dec 11, 2006 at 10:16:30AM -0500, Jeff Garzik ([EMAIL PROTECTED]) wrote: Comments: * [oh, everybody will hate me for saying this, but...] to me, "kevent" implies an internal kernel subsystem. I would rather call it "uevent" or anything else lacking a 'k' prefix. It is kernel subsystem indeed, which exports some of its part to userspace. I previously thought that prefix 'k' can only be confused with KDE. It is a true statement to say "without the kevent subsystem, userspace lacks uevent handling". And let's be honest, the main consumers of this will be userspace apps, and a few in-kernel users pretending to be userspace apps (kernel threads). Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [take26-resend1 0/8] kevent: Generic event handling mechanism.
Evgeniy Polyakov wrote: On Mon, Dec 11, 2006 at 10:16:30AM -0500, Jeff Garzik ([EMAIL PROTECTED]) wrote: Comments: * [oh, everybody will hate me for saying this, but...] to me, kevent implies an internal kernel subsystem. I would rather call it uevent or anything else lacking a 'k' prefix. It is kernel subsystem indeed, which exports some of its part to userspace. I previously thought that prefix 'k' can only be confused with KDE. It is a true statement to say without the kevent subsystem, userspace lacks uevent handling. And let's be honest, the main consumers of this will be userspace apps, and a few in-kernel users pretending to be userspace apps (kernel threads). Jeff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [take26-resend1 0/8] kevent: Generic event handling mechanism.
On Mon, Dec 11, 2006 at 10:16:30AM -0500, Jeff Garzik ([EMAIL PROTECTED]) wrote: > Comments: > > * [oh, everybody will hate me for saying this, but...] to me, "kevent" > implies an internal kernel subsystem. I would rather call it "uevent" > or anything else lacking a 'k' prefix. It is kernel subsystem indeed, which exports some of its part to userspace. I previously thought that prefix 'k' can only be confused with KDE. > * I like the absolute timespec (and use of timespec itself) And I do not, but I made them to make at least some progress. > * more on naming: I think kevent_open would be more natural than > kevent_init, since it opens a file descriptor. It is also initializes ring buffer. > * why is KEVENT_MAX not equal to KEVENT_POSIX_TIMER? (perhaps answer > this question in a comment, if it is not a mistake) I check for error number using '>=' and use it as array size, so it is always bigger than the last entry id. I will add a comment. > * Kill all the CONFIG_KEVENT_xxx sub-options, or hide them under > CONFIG_EMBEDDED. Application developers should NOT be left wondering > whether or support for KEVENT_INODE was compiled into the kernel. Ok, I will put them under !CONFIG_EMBEDDED. -- Evgeniy Polyakov - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [take26-resend1 0/8] kevent: Generic event handling mechanism.
Comments: * [oh, everybody will hate me for saying this, but...] to me, "kevent" implies an internal kernel subsystem. I would rather call it "uevent" or anything else lacking a 'k' prefix. * I like the absolute timespec (and use of timespec itself) * more on naming: I think kevent_open would be more natural than kevent_init, since it opens a file descriptor. * why is KEVENT_MAX not equal to KEVENT_POSIX_TIMER? (perhaps answer this question in a comment, if it is not a mistake) * Kill all the CONFIG_KEVENT_xxx sub-options, or hide them under CONFIG_EMBEDDED. Application developers should NOT be left wondering whether or support for KEVENT_INODE was compiled into the kernel. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[take26-resend1 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=kevent Documentation page: http://linux-net.osdl.org/index.php/Kevent I installed slightly used, but still functional (bought on ebay) remote mind reader, and set it up to read Ulrich's alpha brain waves (I hope he agrees that it is a good decision), which took me the whole week. So I think the last ring buffer implementation is what we all wanted. Details in documentation part. It seems that setup was correct and we finially found what we wanted from interface part. No changes since previous version, since it is a resend of the previous release made more than a week ago, which did not received any feedback. Consider for inclusion. 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 on possible number of kevents Changes from 'take19' patchset: * use __init instead of __devinit * removed 'default N' from config for user statistic * removed kevent_user_fini() since kevent can not be unloaded * use KERN_INFO for statistic output Changes from 'take18' patchset: * use __init instead of __devinit * removed 'default N' from config for user statistic * removed kevent_user_fini() since kevent can not be unloaded * use KERN_INFO for statistic output Changes from 'take17' patchset: * Use RB tree instead of hash table. At least for a web sever, frequency of addition/deletion of new kevent is comparable with number of search access, i.e. most of the time events are added, accesed only couple of times and then removed, so it justifies RB tree usage over AVL tree, since the latter does have much slower deletion time (max O(log(N)) compared to 3 ops), although faster search time (1.44*O(log(N)) vs. 2*O(log(N))). So for kevents I use RB tree for now and later, when my AVL tree implementation is ready, it will be possible to compare them. * Changed readiness check for socket notifications. With both above changes it is possible to achieve more than 3380 req/second compared to 2200, sometimes 2500 req/second for epoll() for trivial web-server and httperf client on the same
[take26-resend1 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=projectsitem=kevent Documentation page: http://linux-net.osdl.org/index.php/Kevent I installed slightly used, but still functional (bought on ebay) remote mind reader, and set it up to read Ulrich's alpha brain waves (I hope he agrees that it is a good decision), which took me the whole week. So I think the last ring buffer implementation is what we all wanted. Details in documentation part. It seems that setup was correct and we finially found what we wanted from interface part. No changes since previous version, since it is a resend of the previous release made more than a week ago, which did not received any feedback. Consider for inclusion. 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 on possible number of kevents Changes from 'take19' patchset: * use __init instead of __devinit * removed 'default N' from config for user statistic * removed kevent_user_fini() since kevent can not be unloaded * use KERN_INFO for statistic output Changes from 'take18' patchset: * use __init instead of __devinit * removed 'default N' from config for user statistic * removed kevent_user_fini() since kevent can not be unloaded * use KERN_INFO for statistic output Changes from 'take17' patchset: * Use RB tree instead of hash table. At least for a web sever, frequency of addition/deletion of new kevent is comparable with number of search access, i.e. most of the time events are added, accesed only couple of times and then removed, so it justifies RB tree usage over AVL tree, since the latter does have much slower deletion time (max O(log(N)) compared to 3 ops), although faster search time (1.44*O(log(N)) vs. 2*O(log(N))). So for kevents I use RB tree for now and later, when my AVL tree implementation is ready, it will be possible to compare them. * Changed readiness check for socket notifications. With both above changes it is possible to achieve more than 3380 req/second compared to 2200, sometimes 2500 req/second for epoll() for trivial web-server and httperf client on the
Re: [take26-resend1 0/8] kevent: Generic event handling mechanism.
Comments: * [oh, everybody will hate me for saying this, but...] to me, kevent implies an internal kernel subsystem. I would rather call it uevent or anything else lacking a 'k' prefix. * I like the absolute timespec (and use of timespec itself) * more on naming: I think kevent_open would be more natural than kevent_init, since it opens a file descriptor. * why is KEVENT_MAX not equal to KEVENT_POSIX_TIMER? (perhaps answer this question in a comment, if it is not a mistake) * Kill all the CONFIG_KEVENT_xxx sub-options, or hide them under CONFIG_EMBEDDED. Application developers should NOT be left wondering whether or support for KEVENT_INODE was compiled into the kernel. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [take26-resend1 0/8] kevent: Generic event handling mechanism.
On Mon, Dec 11, 2006 at 10:16:30AM -0500, Jeff Garzik ([EMAIL PROTECTED]) wrote: Comments: * [oh, everybody will hate me for saying this, but...] to me, kevent implies an internal kernel subsystem. I would rather call it uevent or anything else lacking a 'k' prefix. It is kernel subsystem indeed, which exports some of its part to userspace. I previously thought that prefix 'k' can only be confused with KDE. * I like the absolute timespec (and use of timespec itself) And I do not, but I made them to make at least some progress. * more on naming: I think kevent_open would be more natural than kevent_init, since it opens a file descriptor. It is also initializes ring buffer. * why is KEVENT_MAX not equal to KEVENT_POSIX_TIMER? (perhaps answer this question in a comment, if it is not a mistake) I check for error number using '=' and use it as array size, so it is always bigger than the last entry id. I will add a comment. * Kill all the CONFIG_KEVENT_xxx sub-options, or hide them under CONFIG_EMBEDDED. Application developers should NOT be left wondering whether or support for KEVENT_INODE was compiled into the kernel. Ok, I will put them under !CONFIG_EMBEDDED. -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
