Re: [take28-resend_2->0 0/8] kevent: Generic event handling mechanism.
On Tue, Dec 19, 2006 at 12:01:35AM -0800, Ulrich Drepper ([EMAIL PROTECTED]) wrote: > Evgeniy Polyakov wrote: > >What error messages do you see and what are kevent related config > >changes? > > ARCH=um > > #define CONFIG_KEVENT_USER_STAT 1 > #define CONFIG_KEVENT_PIPE 1 > #define CONFIG_KEVENT_POLL 1 > #define CONFIG_KEVENT_TIMER 1 > #define CONFIG_KEVENT 1 > #define CONFIG_KEVENT_SIGNAL 1 > #define CONFIG_KEVENT_SOCKET 1 > > > > In file included from kernel/kevent/kevent.c:28: > include/linux/kevent.h: In function ‘kevent_init_file’: > include/linux/kevent.h:220: error: ‘struct file’ has no member named > ‘st’ > include/linux/kevent.h: In function ‘kevent_cleanup_file’: > include/linux/kevent.h:225: error: ‘struct file’ has no member named > ‘st’ Can you send me your linux/fs.h file to chek if it is correct. Also does 'make prepare' fix the buid? > -- > ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, > CA ❖ -- 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: [take28-resend_2->0 0/8] kevent: Generic event handling mechanism.
Evgeniy Polyakov wrote: What error messages do you see and what are kevent related config changes? ARCH=um #define CONFIG_KEVENT_USER_STAT 1 #define CONFIG_KEVENT_PIPE 1 #define CONFIG_KEVENT_POLL 1 #define CONFIG_KEVENT_TIMER 1 #define CONFIG_KEVENT 1 #define CONFIG_KEVENT_SIGNAL 1 #define CONFIG_KEVENT_SOCKET 1 In file included from kernel/kevent/kevent.c:28: include/linux/kevent.h: In function ‘kevent_init_file’: include/linux/kevent.h:220: error: ‘struct file’ has no member named ‘st’ include/linux/kevent.h: In function ‘kevent_cleanup_file’: include/linux/kevent.h:225: error: ‘struct file’ has no member named ‘st’ -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ - 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: [take28-resend_2-0 0/8] kevent: Generic event handling mechanism.
Evgeniy Polyakov wrote: What error messages do you see and what are kevent related config changes? ARCH=um #define CONFIG_KEVENT_USER_STAT 1 #define CONFIG_KEVENT_PIPE 1 #define CONFIG_KEVENT_POLL 1 #define CONFIG_KEVENT_TIMER 1 #define CONFIG_KEVENT 1 #define CONFIG_KEVENT_SIGNAL 1 #define CONFIG_KEVENT_SOCKET 1 In file included from kernel/kevent/kevent.c:28: include/linux/kevent.h: In function ‘kevent_init_file’: include/linux/kevent.h:220: error: ‘struct file’ has no member named ‘st’ include/linux/kevent.h: In function ‘kevent_cleanup_file’: include/linux/kevent.h:225: error: ‘struct file’ has no member named ‘st’ -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ - 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: [take28-resend_2-0 0/8] kevent: Generic event handling mechanism.
On Tue, Dec 19, 2006 at 12:01:35AM -0800, Ulrich Drepper ([EMAIL PROTECTED]) wrote: Evgeniy Polyakov wrote: What error messages do you see and what are kevent related config changes? ARCH=um #define CONFIG_KEVENT_USER_STAT 1 #define CONFIG_KEVENT_PIPE 1 #define CONFIG_KEVENT_POLL 1 #define CONFIG_KEVENT_TIMER 1 #define CONFIG_KEVENT 1 #define CONFIG_KEVENT_SIGNAL 1 #define CONFIG_KEVENT_SOCKET 1 In file included from kernel/kevent/kevent.c:28: include/linux/kevent.h: In function ‘kevent_init_file’: include/linux/kevent.h:220: error: ‘struct file’ has no member named ‘st’ include/linux/kevent.h: In function ‘kevent_cleanup_file’: include/linux/kevent.h:225: error: ‘struct file’ has no member named ‘st’ Can you send me your linux/fs.h file to chek if it is correct. Also does 'make prepare' fix the buid? -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -- 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: [take28-resend_2->0 0/8] kevent: Generic event handling mechanism.
On Mon, Dec 18, 2006 at 10:21:34PM -0800, Ulrich Drepper ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov wrote:
> >I've uploaded the latest changes to the homepage.
>
> Thanks. But could you now update the patch so that it can be compiled
> with the current upstream kernel? At least has
> problems because of file->st accesses.
file->st is only defined for poll/select events, if it is not specified
at compile time, functions in linux/kevent.h becomes void:
#ifdef CONFIG_KEVENT_POLL
static inline void kevent_init_file(struct file *file)
{
kevent_storage_init(file, >st);
}
static inline void kevent_cleanup_file(struct file *file)
{
kevent_storage_fini(>st);
}
#else
static inline void kevent_init_file(struct file *file) {}
static inline void kevent_cleanup_file(struct file *file) {}
#endif
What error messages do you see and what are kevent related config
changes?
> --
> ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View,
> CA ❖
--
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: [take28-resend_2->0 0/8] kevent: Generic event handling mechanism.
Evgeniy Polyakov wrote: I've uploaded the latest changes to the homepage. Thanks. But could you now update the patch so that it can be compiled with the current upstream kernel? At least has problems because of file->st accesses. -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ - 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: [take28-resend_2->0 0/8] kevent: Generic event handling mechanism.
On Mon, Dec 18, 2006 at 07:47:21PM -0800, Ulrich Drepper ([EMAIL PROTECTED]) wrote: > It would help if one could actually get hold of the changes. > > Neither at home nor on my gmail account did I get them all. The gmane > also only has 5 of the 9 mails or so. Your archive only has sources > from a couple of versions back. Kernel archive contains all changes as far as I can see at marc.theaimsgroup.com and lkml.org I've uploaded the latest changes to the homepage. > -- > ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, > CA ❖ -- 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: [take28-resend_2->0 0/8] kevent: Generic event handling mechanism.
On Mon, 18 Dec 2006 19:47:21 -0800 Ulrich Drepper wrote: > It would help if one could actually get hold of the changes. > > Neither at home nor on my gmail account did I get them all. The gmane > also only has 5 of the 9 mails or so. Your archive only has sources > from a couple of versions back. It looks like they are all archived at marc.theaimsgroup.com. Try this: http://marc.theaimsgroup.com/?l=linux-netdev=2=1=take28-resend_2=t But it would be Good for them to have a home. --- ~Randy - 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: [take28-resend_2->0 0/8] kevent: Generic event handling mechanism.
It would help if one could actually get hold of the changes. Neither at home nor on my gmail account did I get them all. The gmane also only has 5 of the 9 mails or so. Your archive only has sources from a couple of versions back. -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ - 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: [take28-resend_2-0 0/8] kevent: Generic event handling mechanism.
It would help if one could actually get hold of the changes. Neither at home nor on my gmail account did I get them all. The gmane also only has 5 of the 9 mails or so. Your archive only has sources from a couple of versions back. -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ - 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: [take28-resend_2-0 0/8] kevent: Generic event handling mechanism.
On Mon, 18 Dec 2006 19:47:21 -0800 Ulrich Drepper wrote: It would help if one could actually get hold of the changes. Neither at home nor on my gmail account did I get them all. The gmane also only has 5 of the 9 mails or so. Your archive only has sources from a couple of versions back. It looks like they are all archived at marc.theaimsgroup.com. Try this: http://marc.theaimsgroup.com/?l=linux-netdevw=2r=1s=take28-resend_2q=t But it would be Good for them to have a home. --- ~Randy - 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: [take28-resend_2-0 0/8] kevent: Generic event handling mechanism.
On Mon, Dec 18, 2006 at 07:47:21PM -0800, Ulrich Drepper ([EMAIL PROTECTED]) wrote: It would help if one could actually get hold of the changes. Neither at home nor on my gmail account did I get them all. The gmane also only has 5 of the 9 mails or so. Your archive only has sources from a couple of versions back. Kernel archive contains all changes as far as I can see at marc.theaimsgroup.com and lkml.org I've uploaded the latest changes to the homepage. -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -- 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: [take28-resend_2-0 0/8] kevent: Generic event handling mechanism.
Evgeniy Polyakov wrote: I've uploaded the latest changes to the homepage. Thanks. But could you now update the patch so that it can be compiled with the current upstream kernel? At least linux/kevent.h has problems because of file-st accesses. -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ - 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: [take28-resend_2-0 0/8] kevent: Generic event handling mechanism.
On Mon, Dec 18, 2006 at 10:21:34PM -0800, Ulrich Drepper ([EMAIL PROTECTED])
wrote:
Evgeniy Polyakov wrote:
I've uploaded the latest changes to the homepage.
Thanks. But could you now update the patch so that it can be compiled
with the current upstream kernel? At least linux/kevent.h has
problems because of file-st accesses.
file-st is only defined for poll/select events, if it is not specified
at compile time, functions in linux/kevent.h becomes void:
#ifdef CONFIG_KEVENT_POLL
static inline void kevent_init_file(struct file *file)
{
kevent_storage_init(file, file-st);
}
static inline void kevent_cleanup_file(struct file *file)
{
kevent_storage_fini(file-st);
}
#else
static inline void kevent_init_file(struct file *file) {}
static inline void kevent_cleanup_file(struct file *file) {}
#endif
What error messages do you see and what are kevent related config
changes?
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View,
CA ❖
--
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/
[take28-resend_2->0 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 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. Thanks for understanding and your time. 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 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
[take28-resend_2-0 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 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. Thanks for understanding and your time. 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 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
