Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3

On Fri, Feb 23, 2007 at 09:43:14AM -0800, Davide Libenzi (davidel@xmailserver.org) wrote: > On Fri, 23 Feb 2007, Evgeniy Polyakov wrote: > > > On Thu, Feb 22, 2007 at 11:46:48AM -0800, Davide Libenzi > > (davidel@xmailserver.org) wrote: > > > > > > A dyna

Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3

On Fri, Feb 23, 2007 at 03:22:25PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED]) wrote: > I meant that we end up with having one thread per IO - they were > preallocated, but that does not matter. And what about your idea of > switching userspace threads to cachemiss threads? > >

Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3

leeping, there is a problem with memory overhead and context switching, although it is usable situation, but when all of them are ready immediately - context switching will kill a machine even with O(1) scheduler which made situation damn better than before, but it is not a cure for the prob

Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3

t own niche, but they can not cover all usage cases. > > - Davide > -- 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: [patch 00/13] Syslets, Threadlets, generic AIO support, v3

-- 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: [patch 00/13] Syslets, Threadlets, generic AIO support, v3

switching, although it is usable situation, but when all of them are ready immediately - context switching will kill a machine even with O(1) scheduler which made situation damn better than before, but it is not a cure for the problem. Ingo -- Evgeniy Polyakov - To unsubscribe from

Re: [patch 00/13] Syslets, Threadlets, generic AIO support, v3

On Fri, Feb 23, 2007 at 03:22:25PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED]) wrote: I meant that we end up with having one thread per IO - they were preallocated, but that does not matter. And what about your idea of switching userspace threads to cachemiss threads? My main concern

Re: [patch 00/13] Syslets, Threadlets, generic AIO support, v3

On Fri, Feb 23, 2007 at 09:43:14AM -0800, Davide Libenzi (davidel@xmailserver.org) wrote: On Fri, 23 Feb 2007, Evgeniy Polyakov wrote: On Thu, Feb 22, 2007 at 11:46:48AM -0800, Davide Libenzi (davidel@xmailserver.org) wrote: A dynamic pool will smooth thread creation/freeing up

Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3

some kind of event delivery mechanism, which would allow to wait on different kinds of events. In the above sentence I see known to pain letters - letter k letter e letter v letter e letter n letter t Or more modern trend - async_wait(epoll). -- Evgeniy Polyakov - To unsubscribe from this list:

[take37 8/10] kevent: Kevent posix timer notifications.

Kevent posix timer notifications. Simple extension to POSIX timers which allows to deliver notification of the timer expiration through kevent queue. Example application posix_timer.c can be found in archive on project homepage. Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]> diff

[take37 9/10] kevent: Private userspace notifications.

Private userspace notifications. Allows to register notifications of any private userspace events over kevent. Events can be marked as ready using kevent_ctl(KEVENT_READY) command. Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]> diff --git a/kernel/kevent/kevent_unotify.c b/kernel/

[take37 10/10] kevent: Kevent based generic AIO.

erver is one-way AMD Athlong 64 3500+) for aio_sendfile_path(). AIO state machine is a base for network AIO (which becomes quite trivial), but I will not start implementation until roadback of kevent as a whole and AIO implementation become more clear. Signed-off-by: Evgeniy Polyakov <[EMAIL PR

[take37 4/10] kevent: Socket notifications.

Socket notifications. This patch includes socket send/recv/accept notifications. Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]> diff --git a/fs/inode.c b/fs/inode.c index 5abb097..b60fa63 100644 --- a/fs/inode.c +++ b/fs/inode.c @@ -21,6 +21,7 @@ #include #include #include +#i

[take37 0/10] kevent: Generic event handling mechanism (socket, pipes, files, signals, AIO, timers, posix timers...).

kevent initialization - use mutuxes instead of semaphores - added file descriptor check and return error if provided descriptor does not match kevent file operations - various indent fixes - removed aio_sendfile() declarations. Thank you. Signed-off-by: Evgeniy Polyakov <[EMAIL

[take37 1/10] kevent: Description.

Description. diff --git a/Documentation/kevent.txt b/Documentation/kevent.txt new file mode 100644 index 000..ee1c381 --- /dev/null +++ b/Documentation/kevent.txt @@ -0,0 +1,276 @@ +Description. + +Kevent documentation + +

[take37 6/10] kevent: Pipe notifications.

gt;fasync_readers, SIGIO, POLL_IN); kill_fasync(>fasync_writers, SIGIO, POLL_OUT); } diff --git a/kernel/kevent/kevent_pipe.c b/kernel/kevent/kevent_pipe.c new file mode 100644 index 000..91dc1eb --- /dev/null +++ b/kernel/kevent/kevent_pipe.c @@ -0,0 +1,123 @@ +/* + * kevent_pipe.c

[take37 7/10] kevent: Signal notifications.

ernel/kevent/kevent_signal.c b/kernel/kevent/kevent_signal.c new file mode 100644 index 000..abe3972 --- /dev/null +++ b/kernel/kevent/kevent_signal.c @@ -0,0 +1,94 @@ +/* + * kevent_signal.c + * + * 2006 Copyright (c) Evgeniy Polyakov <[EMAIL PROTECTED]> + * All rights reserved. + *

[take37 3/10] kevent: poll/select() notifications.

tern spinlock_t files_lock; diff --git a/kernel/kevent/kevent_poll.c b/kernel/kevent/kevent_poll.c new file mode 100644 index 000..58129fa --- /dev/null +++ b/kernel/kevent/kevent_poll.c @@ -0,0 +1,234 @@ +/* + * 2006 Copyright (c) Evgeniy Polyakov <[EMAIL PROTECTED]> + * All rights reserved

[take37 5/10] kevent: Timer notifications.

of nanoseconds Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]> diff --git a/kernel/kevent/kevent_timer.c b/kernel/kevent/kevent_timer.c new file mode 100644 index 000..c21a155 --- /dev/null +++ b/kernel/kevent/kevent_timer.c @@ -0,0 +1,114 @@ +/* + * 2006 Copyright (c) Evgeniy Polyakov &

Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3

On Thu, Feb 22, 2007 at 01:59:31PM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote: > > * Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > > > It is not a TUX anymore - you had 1024 threads, and all of them will > > be consumed by tcp_sendmsg() for slow clients - rescheduli

Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3

d it is likely optimistic result, when designing new type of AIO. > -- > if you want to mail me at work (you don't), use arjan (at) linux.intel.com > Test the interaction between Linux and your BIOS via > http://www.linuxfirmwarekit.org -- Evgeniy Polyakov - To unsubscri

Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3

ore than 20k connections of 80k total block in tcp_sendmsg() over gigabit lan between quite fast machines. Or threadlet/syslet AIO should not be used with networking too? > Ingo -- Evgeniy Polyakov - To unsubscribe from this list: send the line "unsubscribe linux-kernel&quo

Re: [patch 00/13] Syslets, Threadlets, generic AIO support, v3

total block in tcp_sendmsg() over gigabit lan between quite fast machines. Or threadlet/syslet AIO should not be used with networking too? Ingo -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED

Re: [patch 00/13] Syslets, Threadlets, generic AIO support, v3

(at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org -- 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

Re: [patch 00/13] Syslets, Threadlets, generic AIO support, v3

On Thu, Feb 22, 2007 at 01:59:31PM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote: * Evgeniy Polyakov [EMAIL PROTECTED] wrote: It is not a TUX anymore - you had 1024 threads, and all of them will be consumed by tcp_sendmsg() for slow clients - rescheduling will kill a machine. maybe

Re: [patch 00/13] Syslets, Threadlets, generic AIO support, v3

would allow to wait on different kinds of events. In the above sentence I see known to pain letters - letter k letter e letter v letter e letter n letter t Or more modern trend - async_wait(epoll). -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe linux

[take37 5/10] kevent: Timer notifications.

of nanoseconds Signed-off-by: Evgeniy Polyakov [EMAIL PROTECTED] diff --git a/kernel/kevent/kevent_timer.c b/kernel/kevent/kevent_timer.c new file mode 100644 index 000..c21a155 --- /dev/null +++ b/kernel/kevent/kevent_timer.c @@ -0,0 +1,114 @@ +/* + * 2006 Copyright (c) Evgeniy Polyakov [EMAIL

[take37 3/10] kevent: poll/select() notifications.

/kevent_poll.c @@ -0,0 +1,234 @@ +/* + * 2006 Copyright (c) Evgeniy Polyakov [EMAIL PROTECTED] + * All rights reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software

[take37 7/10] kevent: Signal notifications.

/kernel/kevent/kevent_signal.c @@ -0,0 +1,94 @@ +/* + * kevent_signal.c + * + * 2006 Copyright (c) Evgeniy Polyakov [EMAIL PROTECTED] + * All rights reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License

[take37 6/10] kevent: Pipe notifications.

--- /dev/null +++ b/kernel/kevent/kevent_pipe.c @@ -0,0 +1,123 @@ +/* + * kevent_pipe.c + * + * 2006 Copyright (c) Evgeniy Polyakov [EMAIL PROTECTED] + * All rights reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General

[take37 4/10] kevent: Socket notifications.

Socket notifications. This patch includes socket send/recv/accept notifications. Signed-off-by: Evgeniy Polyakov [EMAIL PROTECTED] diff --git a/fs/inode.c b/fs/inode.c index 5abb097..b60fa63 100644 --- a/fs/inode.c +++ b/fs/inode.c @@ -21,6 +21,7 @@ #include linux/cdev.h #include linux

[take37 9/10] kevent: Private userspace notifications.

Private userspace notifications. Allows to register notifications of any private userspace events over kevent. Events can be marked as ready using kevent_ctl(KEVENT_READY) command. Signed-off-by: Evgeniy Polyakov [EMAIL PROTECTED] diff --git a/kernel/kevent/kevent_unotify.c b/kernel/kevent

[take37 8/10] kevent: Kevent posix timer notifications.

Kevent posix timer notifications. Simple extension to POSIX timers which allows to deliver notification of the timer expiration through kevent queue. Example application posix_timer.c can be found in archive on project homepage. Signed-off-by: Evgeniy Polyakov [EMAIL PROTECTED] diff --git

[take37 1/10] kevent: Description.

Description. diff --git a/Documentation/kevent.txt b/Documentation/kevent.txt new file mode 100644 index 000..ee1c381 --- /dev/null +++ b/Documentation/kevent.txt @@ -0,0 +1,276 @@ +Description. + +Kevent documentation + +

[take37 0/10] kevent: Generic event handling mechanism (socket, pipes, files, signals, AIO, timers, posix timers...).

initialization - use mutuxes instead of semaphores - added file descriptor check and return error if provided descriptor does not match kevent file operations - various indent fixes - removed aio_sendfile() declarations. Thank you. Signed-off-by: Evgeniy Polyakov [EMAIL PROTECTED

[take37 10/10] kevent: Kevent based generic AIO.

AMD Athlong 64 3500+) for aio_sendfile_path(). AIO state machine is a base for network AIO (which becomes quite trivial), but I will not start implementation until roadback of kevent as a whole and AIO implementation become more clear. Signed-off-by: Evgeniy Polyakov [EMAIL PROTECTED] diff --git

Re: all syscalls initially taking 4usec on a P4? Re: nonblocking UDPv4 recvfrom() taking 4usec @ 3GHz?

/dev/zero in chunks of 50 bytes ends up with about 190 nanosecond on that machine. -- 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

Re: all syscalls initially taking 4usec on a P4? Re: nonblocking UDPv4 recvfrom() taking 4usec @ 3GHz?

/dev/zero in chunks of 50 bytes ends up with about 190 nanosecond on that machine. -- 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

Re: all syscalls initially taking 4usec on a P4? Re: nonblocking UDPv4 recvfrom() taking 4usec @ 3GHz?

4 cycles = 0.34 us Likely first overhead related to cache population or gamma-ray radiation. If it happens only one (it does in my test), then everything is ok I think. Bert, how frequently you get that long recvfrom()? -- Evgeniy Polyakov - To unsubscribe from this list: sen

Re: all syscalls initially taking 4usec on a P4? Re: nonblocking UDPv4 recvfrom() taking 4usec @ 3GHz?

On Tue, Feb 20, 2007 at 08:11:20PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED]) wrote: > I would try it today - but it is a bit late in Moscow already - and > there are some things to complete yet. So, tomorrow I will create a patch > and run it, but I seriously doubt that there is _that_

Re: all syscalls initially taking 4usec on a P4? Re: nonblocking UDPv4 recvfrom() taking 4usec @ 3GHz?

On Tue, Feb 20, 2007 at 06:02:32PM +0100, bert hubert ([EMAIL PROTECTED]) wrote: > On Tue, Feb 20, 2007 at 07:41:25PM +0300, Evgeniy Polyakov wrote: > > > It can be recvfrom only problem - syscall overhead on my p4 (core duo, > > debian testing) is bout 300 usec - to test I

Re: all syscalls initially taking 4usec on a P4? Re: nonblocking UDPv4 recvfrom() taking 4usec @ 3GHz?

y p4 (core duo, debian testing) is bout 300 usec - to test I ran read('dev/zero', , 0) in a loop. Could you try to hack recvfrom() for your socket to always copy some empty buffer and check the results without waiting for packet? If you are not hurry I can test it myself tomorrow. -- Evg

Re: all syscalls initially taking 4usec on a P4? Re: nonblocking UDPv4 recvfrom() taking 4usec @ 3GHz?

usec - to test I ran read('dev/zero', data, 0) in a loop. Could you try to hack recvfrom() for your socket to always copy some empty buffer and check the results without waiting for packet? If you are not hurry I can test it myself tomorrow. -- Evgeniy Polyakov - To unsubscribe from

Re: all syscalls initially taking 4usec on a P4? Re: nonblocking UDPv4 recvfrom() taking 4usec @ 3GHz?

On Tue, Feb 20, 2007 at 06:02:32PM +0100, bert hubert ([EMAIL PROTECTED]) wrote: On Tue, Feb 20, 2007 at 07:41:25PM +0300, Evgeniy Polyakov wrote: It can be recvfrom only problem - syscall overhead on my p4 (core duo, debian testing) is bout 300 usec - to test I ran read('dev/zero', data

Re: all syscalls initially taking 4usec on a P4? Re: nonblocking UDPv4 recvfrom() taking 4usec @ 3GHz?

On Tue, Feb 20, 2007 at 08:11:20PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED]) wrote: I would try it today - but it is a bit late in Moscow already - and there are some things to complete yet. So, tomorrow I will create a patch and run it, but I seriously doubt that there is _that_ high per

Re: all syscalls initially taking 4usec on a P4? Re: nonblocking UDPv4 recvfrom() taking 4usec @ 3GHz?

related to cache population or gamma-ray radiation. If it happens only one (it does in my test), then everything is ok I think. Bert, how frequently you get that long recvfrom()? -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message

Re: [patch 08/14] syslets: x86, add create_async_thread() method

er; > + regs.xcs = __KERNEL_CS | get_kernel_rpl(); > + regs.eflags = X86_EFLAGS_IF | X86_EFLAGS_SF | X86_EFLAGS_PF | 0x2; > + > + /* Ok, create the new task.. */ > + return do_fork(flags, 0, , 0, NULL, NULL); > +} What about complete disabling of signals and only enablin

Re: [patch 05/11] syslets: core code

ink_about. > > Period > > Please listen to those of us who are saying that this might not be the > case. Maybe we're idiots, but then again maybe we're not, okay? > Sometimes the API really *DOES* change the underlying implementation. It is exactly the time to say what i

Re: [patch 05/11] syslets: core code

On Fri, Feb 16, 2007 at 11:20:36PM +0300, Cyrill V. Gorcunov ([EMAIL PROTECTED]) wrote: > On Fri, Feb 16, 2007 at 07:58:54PM +0300, Evgeniy Polyakov wrote: > | Absolutely. > | And if overall system design is good, there is no problem to change > | (well, for those who fail to rea

Re: [patch 05/11] syslets: core code

On Fri, Feb 16, 2007 at 11:20:36PM +0300, Cyrill V. Gorcunov ([EMAIL PROTECTED]) wrote: On Fri, Feb 16, 2007 at 07:58:54PM +0300, Evgeniy Polyakov wrote: | Absolutely. | And if overall system design is good, there is no problem to change | (well, for those who fail to read to the end

Re: [patch 05/11] syslets: core code

not, okay? Sometimes the API really *DOES* change the underlying implementation. It is exactly the time to say what interface sould be good. System is almost ready - it is time to make it looks cool for users. Ray -- Evgeniy Polyakov - To unsubscribe from this list: send the line

Re: [patch 08/14] syslets: x86, add create_async_thread() method

= X86_EFLAGS_IF | X86_EFLAGS_SF | X86_EFLAGS_PF | 0x2; + + /* Ok, create the new task.. */ + return do_fork(flags, 0, regs, 0, NULL, NULL); +} What about complete disabling of signals and only enabling them in the thread which returns to userspace? -- Evgeniy Polyakov

Re: Using kevent for event logging?

On Fri, Feb 16, 2007 at 06:33:35PM +0100, Michael Holzheu ([EMAIL PROTECTED]) wrote: > Hi Evgeniy, Hi Michael. > On Friday 16 February 2007 16:06, Evgeniy Polyakov wrote: > > On Fri, Feb 16, 2007 at 03:57:08PM +0100, Michael Holzheu ([EMAIL > > PROTECTED]) wrote: > > &

Re: [patch 05/11] syslets: core code

On Fri, Feb 16, 2007 at 08:53:30AM -0800, Ray Lee ([EMAIL PROTECTED]) wrote: > On 2/16/07, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > >if its design is good, then > >interface can be changed in a moment without any problem > > This isn't always the case. S

Re: [patch 05/11] syslets: core code

s. But my above words are too lame for self-hearing Olympus liver. Definitely. > Linus -- 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

Re: Using kevent for event logging?

int, kevent requires some requests from userspace which can be marked as ready, while netlink allows to generate them from 'void' (i.e. withoug userspace creating request). > Michael -- Evgeniy Polyakov - To unsubscribe from this list: send the line "unsubscribe linux-kernel"

Re: [patch 05/11] syslets: core code

e who asked about its features, it looks like there is no need for that at all. -- 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/majordom

Re: [patch 05/11] syslets: core code

at - so I ask you about your opinion, and instead of getting an answer I receive theoretical word-fall about how perfect interface should look like. You only need to have one function call without ever thinking bout freeing? I proposed _two_ ways to that. You can live with explicit init/cleanup

Re: [patch 05/11] syslets: core code

with explicit init/cleanup (opt) code? There is another one. So please decribe your vision of interface with details, so that it could be think about or/and implemented. Linus -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body

Re: [patch 05/11] syslets: core code

like there is no need for that at all. -- 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: Using kevent for event logging?

be marked as ready, while netlink allows to generate them from 'void' (i.e. withoug userspace creating request). Michael -- 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

Re: [patch 05/11] syslets: core code

for self-hearing Olympus liver. Definitely. Linus -- 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

Re: [patch 05/11] syslets: core code

On Fri, Feb 16, 2007 at 08:53:30AM -0800, Ray Lee ([EMAIL PROTECTED]) wrote: On 2/16/07, Evgeniy Polyakov [EMAIL PROTECTED] wrote: if its design is good, then interface can be changed in a moment without any problem This isn't always the case. Sometimes the interface puts requirements

Re: Using kevent for event logging?

On Fri, Feb 16, 2007 at 06:33:35PM +0100, Michael Holzheu ([EMAIL PROTECTED]) wrote: Hi Evgeniy, Hi Michael. On Friday 16 February 2007 16:06, Evgeniy Polyakov wrote: On Fri, Feb 16, 2007 at 03:57:08PM +0100, Michael Holzheu ([EMAIL PROTECTED]) wrote: You will need to have

Re: [patch 05/11] syslets: core code

://www.PowerDNS.com Open source, database driven DNS Software > http://netherlabs.nl Open and Closed source services -- 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: [patch 05/11] syslets: core code

ended... So, describe how exactly _you_ think it should be implemented with its pros and cons, so that systemn could be adopted without trying to mind-read of what is simple and good or complex and really bad. > Linus -- 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: [patch 05/11] syslets: core code

On Thu, Feb 15, 2007 at 09:42:32AM -0800, Linus Torvalds ([EMAIL PROTECTED]) wrote: > > > On Thu, 15 Feb 2007, Evgeniy Polyakov wrote: > > > > Userspace_API_is_the_ever_possible_last_thing_to_ever_think_about. Period > > . // <- wrapped one > > No, I rea

Re: [patch 06/14] syslets: core, documentation

be solved for pointer size? Is it better to wire longs/pointers to 64 bits right now? -- 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/majordom

Re: [patch 05/11] syslets: core code

On Thu, Feb 15, 2007 at 09:39:33AM -0800, Davide Libenzi (davidel@xmailserver.org) wrote: > On Thu, 15 Feb 2007, Evgeniy Polyakov wrote: > > > On Thu, Feb 15, 2007 at 09:05:13AM -0800, Davide Libenzi > > (davidel@xmailserver.org) wrote: > > > > > > I

Re: [patch 05/11] syslets: core code

would be able to perform not only syscalls, but any kernel interfaces suitable prototypes, v2 seems to move that direction) are called asynchronously from main userspace thread to achieve the maximum performance. > - Davide > -- Evgeniy Polyakov - To unsubscribe from this list: sen

Re: [patch 05/11] syslets: core code

do a "open + stat" looks like a fine thing. But I doubt > you'll see a lot of other combinations. Then no problem. Interface does suck, especially since it does not allow to forbid some syscalls from async execution, but it is just a brick which allows to build really good system of it

Re: [patch 05/11] syslets: core code

current form likely will not be used except maybe some optional hints for IO tasks like fadvice) c. in all other ways it has all pros and cons of micro-thread design (it looks neat and simple, although is utterly broken in some usage cases). >

Re: [patch 05/11] syslets: core code

cases). Linus -- 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

Re: [patch 05/11] syslets: core code

. Linus -- 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: [patch 05/11] syslets: core code

to achieve the maximum performance. - Davide -- 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

Re: [patch 05/11] syslets: core code

On Thu, Feb 15, 2007 at 09:39:33AM -0800, Davide Libenzi (davidel@xmailserver.org) wrote: On Thu, 15 Feb 2007, Evgeniy Polyakov wrote: On Thu, Feb 15, 2007 at 09:05:13AM -0800, Davide Libenzi (davidel@xmailserver.org) wrote: I actually think that building chains of syscalls bring

Re: [patch 06/14] syslets: core, documentation

? Is it better to wire longs/pointers to 64 bits right now? -- 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

Re: [patch 05/11] syslets: core code

On Thu, Feb 15, 2007 at 09:42:32AM -0800, Linus Torvalds ([EMAIL PROTECTED]) wrote: On Thu, 15 Feb 2007, Evgeniy Polyakov wrote: Userspace_API_is_the_ever_possible_last_thing_to_ever_think_about. Period . // - wrapped one No, I really think you're wrong. In many ways

Re: [patch 05/11] syslets: core code

); } Although that cruft might need to be extended... So, describe how exactly _you_ think it should be implemented with its pros and cons, so that systemn could be adopted without trying to mind-read of what is simple and good or complex and really bad. Linus -- Evgeniy Polyakov

Re: [patch 05/11] syslets: core code

-- 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: [patch 00/11] ANNOUNCE: "Syslets", generic asynchronous system call support

o reuse syslet state machine in kevent AIO instead of own (althtough own one lacks only one good feature of syslets threads currently - its set of threads is global, but not per-task, which does not allow to scale good with number of different processes doing IO) so to not duplicate the code if kev

Re: [patch 05/11] syslets: core code

(-u) 7168 virtual memory(kbytes, -v) unlimited $ cat /etc/mandrake-release Mandrake Linux release 10.0 (Community) for i586 Anyway, even if there is a limit like in fc5 - 32kb, so I doubt any unpriveledged userspace application will ever run there. -- Evgeniy Polyakov

Re: [patch 05/11] syslets: core code

On Wed, Feb 14, 2007 at 10:46:29AM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote: > > * Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > > > This will end up badly - I used the same approach in the early kevent > > days and was proven to have swapable memory for the

Re: [patch 05/11] syslets: core code

to have swapable memory for the ring. I think it would be much better to have userspace allocated ring and use copy_to_user() there. Btw, as a bit of advertisement, the whole completion part can be done through kevent which already has ring buffer, queue operations and non-racy updates... :) >

Re: [patch 00/11] ANNOUNCE: "Syslets", generic asynchronous system call support

On Tue, Feb 13, 2007 at 11:18:10PM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote: > > * Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > > > [...] it still has a problem - syscall blocks and the same thread thus > > is not allowed to continue execution and fill the pi

Re: [patch 00/11] ANNOUNCE: Syslets, generic asynchronous system call support

On Tue, Feb 13, 2007 at 11:18:10PM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote: * Evgeniy Polyakov [EMAIL PROTECTED] wrote: [...] it still has a problem - syscall blocks and the same thread thus is not allowed to continue execution and fill the pipe - so what if system issues

Re: [patch 05/11] syslets: core code

it would be much better to have userspace allocated ring and use copy_to_user() there. Btw, as a bit of advertisement, the whole completion part can be done through kevent which already has ring buffer, queue operations and non-racy updates... :) Ingo -- Evgeniy Polyakov

Re: [patch 05/11] syslets: core code

On Wed, Feb 14, 2007 at 10:46:29AM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote: * Evgeniy Polyakov [EMAIL PROTECTED] wrote: This will end up badly - I used the same approach in the early kevent days and was proven to have swapable memory for the ring. I think it would be much better

Re: [patch 05/11] syslets: core code

memory(kbytes, -v) unlimited $ cat /etc/mandrake-release Mandrake Linux release 10.0 (Community) for i586 Anyway, even if there is a limit like in fc5 - 32kb, so I doubt any unpriveledged userspace application will ever run there. -- Evgeniy Polyakov - To unsubscribe from this list

Re: [patch 00/11] ANNOUNCE: Syslets, generic asynchronous system call support

lacks only one good feature of syslets threads currently - its set of threads is global, but not per-task, which does not allow to scale good with number of different processes doing IO) so to not duplicate the code if kevent is ever be possible to get into. -- Evgeniy Polyakov

Re: [patch 00/11] ANNOUNCE: "Syslets", generic asynchronous system call support

l next $sys_async_wait are ready)? -- 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: [patch 00/11] ANNOUNCE: "Syslets", generic asynchronous system call support

this state machine and interface to allow that (so that some other state machine implementations would not continue its life :)? > Ingo -- 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: [patch 00/11] ANNOUNCE: Syslets, generic asynchronous system call support

-- 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: [patch 00/11] ANNOUNCE: Syslets, generic asynchronous system call support

$sys_async_wait are ready)? -- 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: [take35 0/10] kevent: Generic event handling mechanism.

On Mon, Feb 12, 2007 at 09:13:35AM -0800, Andrew Morton ([EMAIL PROTECTED]) wrote: > > On Mon, 12 Feb 2007 13:35:10 +0300 Evgeniy Polyakov <[EMAIL PROTECTED]> > > wrote: > > Andrew, do you consider kevent for inclusion or declining? > > I haven't had time to th

Re: [take35 0/10] kevent: Generic event handling mechanism.

On Mon, Feb 12, 2007 at 06:59:17AM -0800, Ulrich Drepper ([EMAIL PROTECTED]) wrote: > Evgeniy Polyakov wrote: > > I think that mean that everybody is happy with APi, design and set of > > features. > > No comment means that I still have not been able to test anything since

Re: [take36 10/10] kevent: Kevent based generic AIO.

req = kaio_add_call(NULL, first_call) kaio_append_call(req, second_call); kaio_append_call(req, third_call); ... kaio_schedule_req(req); Yes, state machine handling requires additional code, but when it ends up in faster processing implementation complexities deserve its price. > Alan --

Re: [take36 10/10] kevent: Kevent based generic AIO.

On Mon, Feb 12, 2007 at 02:08:10PM +0100, Andi Kleen ([EMAIL PROTECTED]) wrote: > Evgeniy Polyakov <[EMAIL PROTECTED]> writes: > > > > aio_sendfile_path() is essentially aio_sendfile(), except that it takes > > source filename as parameter, has a pointer to private hea

[take36 5/10] kevent: Timer notifications.

of nanoseconds Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]> diff --git a/kernel/kevent/kevent_timer.c b/kernel/kevent/kevent_timer.c new file mode 100644 index 000..c21a155 --- /dev/null +++ b/kernel/kevent/kevent_timer.c @@ -0,0 +1,114 @@ +/* + * 2006 Copyright (c) Evgeniy Polyakov &

[take36 4/10] kevent: Socket notifications.

Socket notifications. This patch includes socket send/recv/accept notifications. Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]> diff --git a/fs/inode.c b/fs/inode.c index bf21dc6..82817b1 100644 --- a/fs/inode.c +++ b/fs/inode.c @@ -21,6 +21,7 @@ #include #include #include +#i

<    4   5   6   7   8   9   10   11   12   13   >