[patch 11/13] signal/timer/event fds v10 - eventfd wire up i386 arch ...

2007-04-02 Thread Davide Libenzi
This patch wire the eventfd system call to the i386 architecture. Signed-off-by: Davide Libenzi davidel@xmailserver.org - Davide Index: linux-2.6.21-rc5.fds/arch/i386/kernel/syscall_table.S === --- linux-2.6.21-rc5.fds.orig

[patch 2/13] signal/timer/event fds v10 - signalfd core ...

2007-04-02 Thread Davide Libenzi
*/ __u64 utime;/* si_utime */ __u64 stime;/* si_stime */ __u64 addr; /* si_addr */ }; Signed-off-by: Davide Libenzi davidel@xmailserver.org - Davide Index: linux-2.6.21-rc5.fds/fs/signalfd.c

Re: getting processor numbers

2007-04-03 Thread Davide Libenzi
On Tue, 3 Apr 2007, Ulrich Drepper wrote: More and more code depends on knowing the number of processors in the system to efficiently scale the code. E.g., in OpenMP it is used by default to determine how many threads to create. Creating more threads than there are processors/cores doesn't

Re: 2.6.21-rc5-mm4

2007-04-03 Thread Davide Libenzi
On Tue, 3 Apr 2007, Randy Dunlap wrote: On Mon, 2 Apr 2007 22:47:45 -0700 Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm4/ - The oops in git-net.patch has been fixed, so that tree has been restored. It is huge. -

[patch 5/5] new fds fixes for 2.6.21-rc5.mm4 - eventfd include files diet ...

2007-04-03 Thread Davide Libenzi
Removes a few unneeded include files from the eventfd code. Signed-off-by: Davide Libenzi davidel@xmailserver.org - Davide Index: linux-2.6.21-rc5.mm4/fs/eventfd.c === --- linux-2.6.21-rc5.mm4.orig/fs/eventfd.c 2007-04-03

[patch 2/5] new fds fixes for 2.6.21-rc5.mm4 - fix a spelling error ...

2007-04-03 Thread Davide Libenzi
Fixes a spelling error inside init/Kconfig. Signed-off-by: Davide Libenzi davidel@xmailserver.org - Davide Index: linux-2.6.21-rc5.mm4/init/Kconfig === --- linux-2.6.21-rc5.mm4.orig/init/Kconfig 2007-04-03 13:17

[patch 4/5] new fds fixes for 2.6.21-rc5.mm4 - timerfd include files diet ...

2007-04-03 Thread Davide Libenzi
Removes a few unneeded include files from the timerfd code. Signed-off-by: Davide Libenzi davidel@xmailserver.org - Davide Index: linux-2.6.21-rc5.mm4/fs/timerfd.c === --- linux-2.6.21-rc5.mm4.orig/fs/timerfd.c 2007-04-03

[patch 1/5] new fds fixes for 2.6.21-rc5.mm4 - fix a build error on x86_64 when the new CONFIG_* are not set ...

2007-04-03 Thread Davide Libenzi
Fixes a build error on x86_64 that happens when the new CONFIG_* options for the new fds are not set Signed-off-by: Davide Libenzi davidel@xmailserver.org - Davide Index: linux-2.6.21-rc5.mm4/kernel/sys_ni.c === --- linux

[patch 3/5] new fds fixes for 2.6.21-rc5.mm4 - signalfd include files diet ...

2007-04-03 Thread Davide Libenzi
Removes a few unneeded include files from the signalfd code. Signed-off-by: Davide Libenzi davidel@xmailserver.org - Davide Index: linux-2.6.21-rc5.mm4/fs/signalfd.c === --- linux-2.6.21-rc5.mm4.orig/fs/signalfd.c 2007-04

[patch 1/3] epoll cleanups - epoll include diet ...

2007-04-03 Thread Davide Libenzi
Remove some unneeded include files from epoll code. Signed-off-by: Davide Libenzi davidel@xmailserver.org - Davide Index: linux-2.6.21-rc5.mm4/fs/eventpoll.c === --- linux-2.6.21-rc5.mm4.orig/fs/eventpoll.c2007-04-03 17:59

[patch 2/3] epoll cleanups - epoll no module ...

2007-04-03 Thread Davide Libenzi
Epoll is either compiled it, or not (if EMBEDDED). Remove the module code and use fs_initcall(). Signed-off-by: Davide Libenzi davidel@xmailserver.org - Davide Index: linux-2.6.21-rc5.mm4/fs/eventpoll.c === --- linux-2.6.21

[patch 3/3] epoll cleanups - epoll remove static pre-declarations and akpm-ize the code ...

2007-04-03 Thread Davide Libenzi
Re-arrange epoll code to avoid static functions pre-declarations, and apply akpm-filter on it. Signed-off-by: Davide Libenzi davidel@xmailserver.org - Davide Index: linux-2.6.21-rc5.mm4/fs/eventpoll.c === --- linux-2.6.21-rc5

Re: 2.6.24-rc6: possible recursive locking detected

2008-01-07 Thread Davide Libenzi
On Sun, 6 Jan 2008, Christian Kujau wrote: On Sat, 5 Jan 2008, Davide Libenzi wrote: A solution may be to move the call to ep_poll_safewake() (that'd become a simple wake_up()) inside a tasklet or whatever is today trendy for delayed work. But his kinda scares me to be honest, since epoll

Re: [PATCH] Improve scalability of epoll_ctl

2008-01-08 Thread Davide Libenzi
On Tue, 8 Jan 2008, Eric Dumazet wrote: Changli Gao a écrit : Replace the epitem rbtree with a dynamic array to get the constant insertion/deletion/modification time of the file descriptors. Reuse the size argument of epoll_create, however the size must be smaller than the max file

Re: [PATCH 5/6] syslets: add generic syslets infrastructure

2008-01-09 Thread Davide Libenzi
On Thu, 10 Jan 2008, Rusty Russell wrote: On Thursday 10 January 2008 05:16:57 Zach Brown wrote: The latter. A ring is optimal for processing a huge number of requests, but if you're really going to be firing off syslet threads all over the place you're not going to be optimal anyway.

Re: RFC: A revised timerfd API

2007-09-18 Thread Davide Libenzi
On Tue, 18 Sep 2007, Michael Kerrisk wrote: The four designs are: a) A multiplexing timerfd() system call. b) Creating three syscalls analogous to the POSIX timers API (i.e., timerfd_create/timerfd_settime/timerfd_gettime). c) Creating a simplified timerfd() system call that is

Re: [PATCH 2.6.23-rc6] NETWORKING : Edge Triggered EPOLLOUT events get missed for TCP sockets

2007-09-19 Thread Davide Libenzi
On Wed, 19 Sep 2007, Nagendra Tomar wrote: [ ... ] Seems like epoll ate your message too :) Can you repost your bug report and the patch? - Davide - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at

Re: [PATCH 2.6.23-rc6 Resending] NETWORKING : Edge Triggered EPOLLOUT events get missed for TCP sockets

2007-09-19 Thread Davide Libenzi
On Wed, 19 Sep 2007, David Miller wrote: From: Nagendra Tomar [EMAIL PROTECTED] Date: Wed, 19 Sep 2007 15:37:09 -0700 (PDT) With the SOCK_NOSPACE check in tcp_check_space(), this epoll_wait call will not return, even when the incoming acks free the buffers. Note that this patch

Re: [PATCH 2.6.23-rc6 Resending] NETWORKING : Edge Triggered EPOLLOUT events get missed for TCP sockets

2007-09-19 Thread Davide Libenzi
On Wed, 19 Sep 2007, Nagendra Tomar wrote: Definitely not ! The point is that the tcp write space available wakeup does not get called if SOCK_NOSPACE bit is not set. This was fine when the wakeup was merely a wakeup (since SOCK_NOSPACE bit indicated that someone really cared abt the

Re: [PATCH 2.6.23-rc6 Resending] NETWORKING : Edge Triggered EPOLLOUT events get missed for TCP sockets

2007-09-20 Thread Davide Libenzi
On Wed, 19 Sep 2007, Nagendra Tomar wrote: The tcp_check_space() function calls tcp_new_space() only if the SOCK_NOSPACE bit is set in the socket flags. This is causing Edge Triggered EPOLLOUT events to be missed for TCP sockets, as the ep_poll_callback() is not called from the wakeup

Re: [PATCH 2.6.23-rc6 Resending] NETWORKING : Edge Triggered EPOLLOUT events get missed for TCP sockets

2007-09-20 Thread Davide Libenzi
On Thu, 20 Sep 2007, Eric Dumazet wrote: Does it means that with your patch each ACK on a ET managed socket will trigger an epoll event ? Maybe your very sensitive high throuput appication needs to set a flag or something at socket level to ask for such a behavior. The default should

[patch] signalfd simplification

2007-09-20 Thread Davide Libenzi
). But it won't work for epoll, since it already expect to install its own callback, and ATM callbacks can't be chained. Since the thundering herd effect on signalfds should be pretty limited, I think it's not worth the change. Signed-off-by: Davide Libenzi [EMAIL PROTECTED] - Davide --- fs/exec.c

Re: Tesing of / bugs in new timerfd API

2007-12-17 Thread Davide Libenzi
On Mon, 17 Dec 2007, Michael Kerrisk wrote: Can you try the two patches below? I tried them on my 32 bit box (one of the rare beasts still lingering around here) and it seems to be working fine (those go on top of the previous ones). Against 2.6.24-rc5, I applied first your earlier

[patch 1/2] timerfd - make hrtimer_forward() to return a u64

2007-12-17 Thread Davide Libenzi
() ticks calculation, ktime_divns(), was already having the result in u64 and it was chopping it to unsigned long. Andrew, this goes on top of the ones you already have in -mm. Signed-off-by: Davide Libenzi [EMAIL PROTECTED] - Davide --- fs/timerfd.c|6 +++--- include/linux

[patch 2/2] timerfd - make the returned time to be the remaining time till the next expiration

2007-12-17 Thread Davide Libenzi
Make the returned time to be the remaining time till the next expiration. If the timer is already expired, and there's no next expiration, zero will be returned. Andrew, this goes on top of the ones you already have in -mm. Signed-off-by: Davide Libenzi [EMAIL PROTECTED] - Davide --- fs

Re: [PATCH] fix group stop with exit race

2007-12-05 Thread Davide Libenzi
(). Signed-off-by: Oleg Nesterov [EMAIL PROTECTED] Looks OK for me, even though we're doing more work on the exit path. OTOH I don't see a non-racy way of doing it w/out grabbing the lock. Did you try to bench how much this change costs? Anyway, looks sane to me... Acked-by: Davide Libenzi

Re: [PATCH] move the related code from exit_notify() to exit_signals()

2007-12-06 Thread Davide Libenzi
On Thu, 6 Dec 2007, Oleg Nesterov wrote: The previous bugfix was not optimal, we shouldn't care about group stop when we are the only thread or the group stop is in progress. In that case nothing special is needed, just set PF_EXITING and return. Also, take the related TIF_SIGPENDING

Re: [PATCHv4 5/6] Allow setting O_NONBLOCK flag for new sockets

2007-11-20 Thread Davide Libenzi
On Tue, 20 Nov 2007, Ingo Molnar wrote: * H. Peter Anvin [EMAIL PROTECTED] wrote: It seems that you're doing the same thing in both cases, except you're now extending it to include other random functionality, which means other things than syslets are suddenly affected. syslets are

Re: Where is the new timerfd?

2007-11-22 Thread Davide Libenzi
On Thu, 22 Nov 2007, Michael Kerrisk wrote: Hey Davide, Where is the new timerfd API. In 2.6.24-rc3, I see the *old* API... Maybe Andrew stuffed the turkey with it? :) It was there. I remeber it was merged. Some screw up reverted it? - Davide - To unsubscribe from this list: send the

Re: Where is the new timerfd?

2007-11-22 Thread Davide Libenzi
On Thu, 22 Nov 2007, Michael Kerrisk wrote: On Nov 22, 2007 6:34 PM, Davide Libenzi [EMAIL PROTECTED] wrote: On Thu, 22 Nov 2007, Michael Kerrisk wrote: Hey Davide, Where is the new timerfd API. In 2.6.24-rc3, I see the *old* API... Maybe Andrew stuffed the turkey

Re: Where is the new timerfd?

2007-11-22 Thread Davide Libenzi
On Thu, 22 Nov 2007, Andrew Morton wrote: On Thu, 22 Nov 2007 11:46:13 -0800 (PST) Davide Libenzi [EMAIL PROTECTED] wrote: On Thu, 22 Nov 2007, Michael Kerrisk wrote: On Nov 22, 2007 6:34 PM, Davide Libenzi [EMAIL PROTECTED] wrote: On Thu, 22 Nov 2007, Michael Kerrisk wrote

[patch 4/4] Timerfd v2 - un-break CONFIG_TIMERFD

2007-11-23 Thread Davide Libenzi
Remove the broken status to CONFIG_TIMERFD. Signed-off-by: Davide Libenzi [EMAIL PROTECTED] - Davide --- init/Kconfig |1 - 1 file changed, 1 deletion(-) Index: linux-2.6.mod/init/Kconfig === --- linux-2.6.mod.orig/init

[patch 1/4] Timerfd v2 - introduce a new hrtimer_forward_now() function

2007-11-23 Thread Davide Libenzi
I think that advancing the timer against the timer's current now can be a pretty common usage, so, w/out exposing hrtimer's internals, we add a new hrtimer_forward_now() function. Signed-off-by: Davide Libenzi [EMAIL PROTECTED] - Davide --- include/linux/hrtimer.h |7 +++ 1 file

Re: Where is the new timerfd?

2007-11-23 Thread Davide Libenzi
On Fri, 23 Nov 2007, Andrew Morton wrote: I suppose this means that timerfd will only go in for 2.6.25. I don't have a problem with that, but we better make sure that the existing timerfd in 2.6.24 is still disabled. (Andrew had a one liner for that, but I haven't checked if it's in

Re: Where is the new timerfd?

2007-11-23 Thread Davide Libenzi
On Fri, 23 Nov 2007, Ulrich Drepper wrote: On Nov 23, 2007 9:29 AM, Davide Libenzi [EMAIL PROTECTED] wrote: Yes, it's disabled, and yes, I'll repost today ... I haven't seen the patch and don't feel like searching. So I say it here: please mak sure you add a flags parameter to the system

[patch 2/4] Timerfd v2 - new timerfd API

2007-11-23 Thread Davide Libenzi
implementation, read(2) and poll(2) are supported (with the same interface). Here's a simple test program I used to exercise the new timerfd APIs: http://www.xmailserver.org/timerfd-test2.c Signed-off-by: Davide Libenzi [EMAIL PROTECTED] - Davide --- fs/compat.c | 32 ++- fs

[patch 3/4] Timerfd v2 - wire the new timerfd API to the x86 family

2007-11-23 Thread Davide Libenzi
Wires up the new timerfd API to the x86 family. Signed-off-by: Davide Libenzi [EMAIL PROTECTED] - Davide --- arch/x86/ia32/ia32entry.S |4 +++- arch/x86/kernel/syscall_table_32.S |4 +++- include/asm-x86/unistd_32.h|6 -- include/asm-x86/unistd_64.h

Re: [patch 2/4] Timerfd v2 - new timerfd API

2007-11-24 Thread Davide Libenzi
On Sat, 24 Nov 2007, Michael Kerrisk wrote: +asmlinkage long sys_timerfd_create(int clockid, int flags) { - int error; + int error, ufd; struct timerfd_ctx *ctx; struct file *file; struct inode *inode; - struct itimerspec ktmr; - - if (copy_from_user(ktmr,

[patch 1/4] Timerfd v3 - introduce a new hrtimer_forward_now() function

2007-11-25 Thread Davide Libenzi
I think that advancing the timer against the timer's current now can be a pretty common usage, so, w/out exposing hrtimer's internals, we add a new hrtimer_forward_now() function. Signed-off-by: Davide Libenzi [EMAIL PROTECTED] - Davide --- include/linux/hrtimer.h |7 +++ 1 file

[patch 2/4] Timerfd v3 - new timerfd API

2007-11-25 Thread Davide Libenzi
implementation, read(2) and poll(2) are supported (with the same interface). Here's a simple test program I used to exercise the new timerfd APIs: http://www.xmailserver.org/timerfd-test2.c Signed-off-by: Davide Libenzi [EMAIL PROTECTED] - Davide --- fs/compat.c | 32 ++- fs

[patch 3/4] Timerfd v3 - wire the new timerfd API to the x86 family

2007-11-25 Thread Davide Libenzi
Wires up the new timerfd API to the x86 family. Signed-off-by: Davide Libenzi [EMAIL PROTECTED] - Davide --- arch/x86/ia32/ia32entry.S |4 +++- arch/x86/kernel/syscall_table_32.S |4 +++- include/asm-x86/unistd_32.h|6 -- include/asm-x86/unistd_64.h

[patch 4/4] Timerfd v3 - un-break CONFIG_TIMERFD

2007-11-25 Thread Davide Libenzi
Remove the broken status to CONFIG_TIMERFD. Signed-off-by: Davide Libenzi [EMAIL PROTECTED] - Davide --- init/Kconfig |1 - 1 file changed, 1 deletion(-) Index: linux-2.6.mod/init/Kconfig === --- linux-2.6.mod.orig/init

Re: [PATCHv4 5/6] Allow setting O_NONBLOCK flag for new sockets

2007-11-26 Thread Davide Libenzi
On Mon, 26 Nov 2007, H. Peter Anvin wrote: Ingo Molnar wrote: So it's not like sys_indirect() would break some magic pristine state of a flat parameter space - on the contrary, most of the nontrivial syscalls take pointers to structures or pointers to streams of information. The

Re: [patch 2/4] Timerfd v3 - new timerfd API

2007-11-27 Thread Davide Libenzi
On Tue, 27 Nov 2007, Andrew Morton wrote: On Sun, 25 Nov 2007 14:14:19 -0800 Davide Libenzi [EMAIL PROTECTED] wrote: +static struct file *timerfd_fget(int fd) +{ + struct file *file; + + file = fget(fd); + if (!file) + return ERR_PTR(-EBADF); + if (file-f_op

Re: [patch 2/4] Timerfd v3 - new timerfd API

2007-11-27 Thread Davide Libenzi
On Tue, 27 Nov 2007, Andrew Morton wrote: On Tue, 27 Nov 2007 12:47:46 -0800 (PST) Davide Libenzi [EMAIL PROTECTED] wrote: On Tue, 27 Nov 2007, Andrew Morton wrote: On Sun, 25 Nov 2007 14:14:19 -0800 Davide Libenzi [EMAIL PROTECTED] wrote: +static struct file *timerfd_fget

Re: 2.6.24-rc3-mm2 - Build Failure on powerpc timerfd() undeclared

2007-11-28 Thread Davide Libenzi
On Wed, 28 Nov 2007, Andrew Morton wrote: On Wed, 28 Nov 2007 14:32:07 +0100 Arnd Bergmann [EMAIL PROTECTED] wrote: On Wednesday 28 November 2007, Kamalesh Babulal wrote: Kernel build fails, with build error   CC      arch/powerpc/platforms/cell/spu_callbacks.o In file included

[patch] update sys_ni.c with the new timerfd syscalls

2007-11-28 Thread Davide Libenzi
Update sys_ni.c with the new timerfd syscalls. Signed-off-by: Davide Libenzi [EMAIL PROTECTED] - Davide --- kernel/sys_ni.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) Index: linux-2.6.mod/kernel/sys_ni.c

Re: Tesing of / bugs in new timerfd API

2007-12-13 Thread Davide Libenzi
On Thu, 13 Dec 2007, Michael Kerrisk wrote: Davide, Andrew, I applied Davide's v3 patchset (sent into LKML on 25 Nov) against 2.4.24-rc3, and did various tests (all on x86). Several tests were done using the program at the foot of this mail. Various others were done by cobbling together

Re: Tesing of / bugs in new timerfd API

2007-12-13 Thread Davide Libenzi
On Thu, 13 Dec 2007, Michael Kerrisk wrote: BUG 2: The last sentence does not match the implementation. (Nor is it consistent with the behavior of POSIX timers. And I *think* things did work correctly in the original timerfd() implementation, but I have not gone back to check.)

Re: Tesing of / bugs in new timerfd API

2007-12-16 Thread Davide Libenzi
On Fri, 14 Dec 2007, Michael Kerrisk wrote: You snipped my example that demonstrated the problem. Both of the following runs create a timer that expires 10 seconds from now, but observe the difference in the value returned by timerfd_gettime(): $ ./timerfd_test 10 # does not use

Re: 2.6.24-rc6: possible recursive locking detected

2008-01-05 Thread Davide Libenzi
On Sat, 5 Jan 2008, Peter Zijlstra wrote: On Sat, 2008-01-05 at 17:53 +0100, Peter Zijlstra wrote: On Sat, 2008-01-05 at 18:12 +1100, Herbert Xu wrote: On Fri, Jan 04, 2008 at 09:30:49AM +0100, Ingo Molnar wrote: [ 1310.670986] =

Re: epoll design problems with common fork/exec patterns

2007-10-27 Thread Davide Libenzi
On Sat, 27 Oct 2007, Marc Lehmann wrote: Please provide some code to illustrate one exact problem you have. // assume there is an open epoll set that listens for events on fd 5 if (fork () = 0) { close (5); // fd 5 is now removed from the epoll set of the parent.

Re: epoll design problems with common fork/exec patterns

2007-10-27 Thread Davide Libenzi
On Sat, 27 Oct 2007, Willy Tarreau wrote: On Sat, Oct 27, 2007 at 09:59:07AM -0700, Davide Libenzi wrote: On Sat, 27 Oct 2007, Marc Lehmann wrote: Please provide some code to illustrate one exact problem you have. // assume there is an open epoll set that listens for events

RE: epoll design problems with common fork/exec patterns

2007-10-28 Thread Davide Libenzi
On Sat, 27 Oct 2007, David Schwartz wrote: I don't see how that can be. Suppose I add fd 8 to an epoll set. Suppose fd 5 is a dup of fd 8. Now, I close fd 8. How can fd 8 remain in my epoll set, since there no longer is an fd 8? Events on files registered for epoll notification are

RE: epoll design problems with common fork/exec patterns

2007-10-29 Thread Davide Libenzi
On Sun, 28 Oct 2007, David Schwartz wrote: Eric Dumazet wrote: Events are not necessarly reported by descriptors. epoll uses an opaque field provided by the user. It's up to the user to properly chose a tag that will makes sense if the user app is playing dup()/close() games for

Re: Revised signalfd man-page

2007-10-17 Thread Davide Libenzi
On Wed, 17 Oct 2007, Michael Kerrisk wrote: With the new code Linus already merged, signalfd does not attach to the sighand anymore, so the orphaned sighand behaviour is no more there. An exec() will carry the fd over, and you will be able to use the fd in the same way you did before

[patch] avoid kmemcheck warning in epoll

2008-02-10 Thread Davide Libenzi
is going to overwrite the node data. In any case I think it's better to not have that happening at all, and fix it by properly initializing the data. Signed-off-by: Davide Libenzi [EMAIL PROTECTED] - Davide --- fs/eventpoll.c |2 +- include/linux/rbtree.h | 12 2 files

[patch] avoid kmemcheck warning in epoll

2008-02-11 Thread Davide Libenzi
is going to overwrite the node data. In any case I think it's better to not have that happening at all, and fix it by simplifying the code to get rid of a few lines that became superfluous after the previous epoll changes. Signed-off-by: Davide Libenzi [EMAIL PROTECTED] - Davide --- fs

Re: [patch] avoid kmemcheck warning in epoll

2008-02-11 Thread Davide Libenzi
On Mon, 11 Feb 2008, Andrew Morton wrote: On Sun, 10 Feb 2008 13:32:01 -0800 (PST) Davide Libenzi [EMAIL PROTECTED] wrote: Epoll calls rb_set_parent(n, n) to initialize the rb-tree node, but rb_set_parent() accesses node's pointer in its code. This creates a warning in kmemcheck

Re: [PATCH 2.6.23-rc6 Resending] NETWORKING : Edge Triggered EPOLLOUT events get missed for TCP sockets

2007-09-20 Thread Davide Libenzi
On Thu, 20 Sep 2007, Nagendra Tomar wrote: --- Davide Libenzi [EMAIL PROTECTED] wrote: Looking back at it, I think the current TCP code is right, once you look at the event to be a output buffer full-with_space transition. If you drop an fd inside epoll with EPOLLOUT|EPOLLET and you

Re: [PATCH 2.6.23-rc6 Resending] NETWORKING : Edge Triggered EPOLLOUT events get missed for TCP sockets

2007-09-21 Thread Davide Libenzi
On Thu, 20 Sep 2007, Nagendra Tomar wrote: That's not what POLLOUT means in the Unix meaning. POLLOUT indicates the ability to write, and it is not meant as to signal every time a packet (skb) is sent on the wire (and the buffer released). Aren't they both the same ? Everytime an

Re: RFC: A revised timerfd API

2007-09-22 Thread Davide Libenzi
On Sat, 22 Sep 2007, Michael Kerrisk wrote: So I'm inclined to implement option (b), unless someone has strong objections. Davide, could I persuade you to help? I guess I better do, otherwise you'll continue to stress me ;) int timerfd_create(int clockid); int timerfd_settime(int ufd, int

Re: RFC: A revised timerfd API

2007-09-22 Thread Davide Libenzi
On Sat, 22 Sep 2007, Thomas Gleixner wrote: On Sat, 2007-09-22 at 14:07 -0700, Davide Libenzi wrote: On Sat, 22 Sep 2007, Michael Kerrisk wrote: So I'm inclined to implement option (b), unless someone has strong objections. Davide, could I persuade you to help? I guess I better

Re: RFC: A revised timerfd API

2007-09-23 Thread Davide Libenzi
On Sun, 23 Sep 2007, Michael Kerrisk wrote: I applied this patch against 2.6.27-rc7, and wired up the syscalls as shown in the definitions below. When I ran the the program below, my system immediately froze. Can you try it on your system please. There's an hrtimer_init() missing in

Re: RFC: A revised timerfd API

2007-09-23 Thread Davide Libenzi
On Sun, 23 Sep 2007, Davide Libenzi wrote: On Sun, 23 Sep 2007, Michael Kerrisk wrote: I applied this patch against 2.6.27-rc7, and wired up the syscalls as shown in the definitions below. When I ran the the program below, my system immediately froze. Can you try it on your system

[patch 1/3] new timerfd API - new timerfd API

2007-09-23 Thread Davide Libenzi
, read(2) and poll(2) are supported (with the same interface). Here's a simple test program I used to exercise the new timerfd APIs: http://www.xmailserver.org/timerfd-test2.c Signed-off-by: Davide Libenzi [EMAIL PROTECTED] - Davide --- fs/compat.c | 32 ++- fs/timerfd.c

[patch 2/3] new timerfd API - wire the new timerfd API to the x86 family

2007-09-23 Thread Davide Libenzi
Wires up the new timerfd API to the x86 family. Signed-off-by: Davide Libenzi [EMAIL PROTECTED] - Davide --- arch/i386/kernel/syscall_table.S |5 - arch/x86_64/ia32/ia32entry.S |4 +++- include/asm-i386/unistd.h|6 -- include/asm-x86_64/unistd.h |8

[patch 3/3] new timerfd API - un-break CONFIG_TIMERFD

2007-09-23 Thread Davide Libenzi
Remove the broken status to CONFIG_TIMERFD. Signed-off-by: Davide Libenzi [EMAIL PROTECTED] - Davide --- init/Kconfig |1 - 1 file changed, 1 deletion(-) Index: linux-2.6.mod/init/Kconfig === --- linux-2.6.mod.orig/init

Re: [patch 2/3] new timerfd API - wire the new timerfd API to the x86 family

2007-09-24 Thread Davide Libenzi
On Mon, 24 Sep 2007, Michael Kerrisk wrote: Davide, Is it perhaps not better to group the three syscalls contiguously with respect to syscall numbers? The old timerfd slot can be re-used for some other syscall later. There's no problem if they're not contiguous. Holes, unless filled

Re: [patch 1/3] new timerfd API - new timerfd API

2007-09-24 Thread Davide Libenzi
On Mon, 24 Sep 2007, Thomas Gleixner wrote: struct timerfd_ctx { struct hrtimer tmr; + int clockid; ktime_t tintv; wait_queue_head_t wqh; int expired; + u64 ticks; }; Can you please restructure the struct in a way which does not result in padding by the

Re: [patch 2/3] new timerfd API - wire the new timerfd API to the x86 family

2007-09-24 Thread Davide Libenzi
On Mon, 24 Sep 2007, Michael Kerrisk wrote: Hi Davide, Davide Libenzi wrote: On Mon, 24 Sep 2007, Michael Kerrisk wrote: Is it perhaps not better to group the three syscalls contiguously with respect to syscall numbers? The old timerfd slot can be re-used for some other syscall later

[patch 1/4] new timerfd API v2 - introduce a new hrtimer_forward_now() function

2007-09-24 Thread Davide Libenzi
I think that advancing the timer against the timer's current now can be a pretty common usage, so, w/out exposing hrtimer's internals, we add a new hrtimer_forward_now() function. Signed-off-by: Davide Libenzi [EMAIL PROTECTED] - Davide --- include/linux/hrtimer.h |7 +++ 1 file

[patch 2/4] new timerfd API v2 - new timerfd API

2007-09-24 Thread Davide Libenzi
, read(2) and poll(2) are supported (with the same interface). Here's a simple test program I used to exercise the new timerfd APIs: http://www.xmailserver.org/timerfd-test2.c Signed-off-by: Davide Libenzi [EMAIL PROTECTED] - Davide --- fs/compat.c | 32 ++- fs/timerfd.c

[patch 3/4] new timerfd API v2 - wire the new timerfd API to the x86 family

2007-09-24 Thread Davide Libenzi
Wires up the new timerfd API to the x86 family. Signed-off-by: Davide Libenzi [EMAIL PROTECTED] - Davide --- arch/i386/kernel/syscall_table.S |5 - arch/x86_64/ia32/ia32entry.S |4 +++- include/asm-i386/unistd.h|6 -- include/asm-x86_64/unistd.h |8

[patch 4/4] new timerfd API v2 - un-break CONFIG_TIMERFD

2007-09-24 Thread Davide Libenzi
Remove the broken status to CONFIG_TIMERFD. Signed-off-by: Davide Libenzi [EMAIL PROTECTED] - Davide --- init/Kconfig |1 - 1 file changed, 1 deletion(-) Index: linux-2.6.mod/init/Kconfig === --- linux-2.6.mod.orig/init

Re: [patch 1/2] Enable link power management for ata drivers

2007-09-24 Thread Davide Libenzi
On Tue, 25 Sep 2007, roel wrote: + if (!(ap-flags ATA_FLAG_IPM) || !ata_dev_enabled(dev)) { if (!((ap-flags ATA_FLAG_IPM) ata_dev_enabled(dev))) { int foo(int i, int j) { return !(i 8) || !j; } int moo(int i, int j) { return !((i 8) j); }

Re: [patch 2/4] new timerfd API v2 - new timerfd API

2007-09-25 Thread Davide Libenzi
On Tue, 25 Sep 2007, Jonathan Corbet wrote: One quick question: Like the previous timerfd API implementation, read(2) and poll(2) are supported (with the same interface). Looking at that interface, it appears that a process doing a read() on a timerfd with no timer set will block

Re: Man page for revised timerfd API

2007-09-26 Thread Davide Libenzi
Michael, SCB ... On Wed, 26 Sep 2007, Michael Kerrisk wrote: .TH TIMERFD_CREATE 2 2007-09-26 Linux Linux Programmer's Manual .SH NAME timerfd_create, timerfd_settime, timer_gettime \- timers that notify via file descriptors .SH SYNOPSIS .\ FIXME . This header file may well change .\

Re: Man page for revised timerfd API

2007-09-27 Thread Davide Libenzi
On Thu, 27 Sep 2007, Michael Kerrisk wrote: Hi Davide, A follow up to the man page text. Does passing a timerfd file descriptor via a Unix domain socket to another process do the expected thing? That is, the receiving process will be able to read from the file descriptor in order to

Re: Man page for revised timerfd API

2007-09-27 Thread Davide Libenzi
On Thu, 27 Sep 2007, Michael Kerrisk wrote: Davide, A further question: what is the expected behavior in the following scenario: 1. Create a timerfd and arm it. 2. Wait until M timer expirations have occurred 3. Modify the settings of the timer 4. Wait for N further timer expirations

Re: eventfd.2 man page

2007-09-27 Thread Davide Libenzi
On Thu, 27 Sep 2007, Michael Kerrisk wrote: Hi Davide, I've slightly tweaked the eventfd.2 man page in preparation for adding it to the man-pages set. Could you please review the text below, and confirm that it correctly describes intended behavior. Looks good to me. At the time that I

Re: Revised signalfd man-page

2007-09-27 Thread Davide Libenzi
On Thu, 27 Sep 2007, Michael Kerrisk wrote: .\ Copyright (C) 2007 Michael Kerrisk [EMAIL PROTECTED] .\ starting from a version by Davide Libenzi [EMAIL PROTECTED] .\ .\ This program is free software; you can redistribute it and/or modify .\ it under the terms of the GNU General Public

[patch] rename signalfd_siginfo fields

2007-09-27 Thread Davide Libenzi
For Michael Kerrisk request, the following patch renames signalfd_siginfo fields in order to keep them consistent with the siginfo_t ones. Signed-off-by: Davide Libenzi [EMAIL PROTECTED] - Davide --- fs/signalfd.c| 44 ++-- include

[patch] anon-inodes use open coded atomic_inc for the shared inode

2007-09-27 Thread Davide Libenzi
Since we know the shared inode count is always 0, we can avoid igrab() and use an open coded atomic_inc(). Signed-off-by: Davide Libenzi [EMAIL PROTECTED] - Davide --- fs/anon_inodes.c | 25 - 1 file changed, 12 insertions(+), 13 deletions(-) Index: linux-2.6.mod

Re: F_DUPFD_CLOEXEC implementation

2007-09-28 Thread Davide Libenzi
On Fri, 28 Sep 2007, Ulrich Drepper wrote: One more small change to extend the availability of creation of file descriptors with FD_CLOEXEC set. Adding a new command to fcntl() requires no new system call and the overall impact on code size if minimal. If this patch gets accepted we will

Re: [rfc][patch] i386: remove comment about barriers

2007-09-29 Thread Davide Libenzi
On Sat, 29 Sep 2007, Nick Piggin wrote: [ This is true for x86's sfence/lfence, but raises a question about Linux's memory barriers. Does anybody expect that a sequence of smp_wmb and smp_rmb would ever provide a full smp_mb barrier? I've always assumed no, but I don't know if it is actually

Re: [PATCH RFC 3/9] RCU: Preemptible RCU

2007-09-30 Thread Davide Libenzi
On Sun, 30 Sep 2007, Oleg Nesterov wrote: Ah, but I asked the different question. We must see CPU 1's stores by definition, but what about CPU 0's stores (which could be seen by CPU 1)? Let's take a real life example, A = B = X = 0; P = Q = A; CPU_0

Re: F_DUPFD_CLOEXEC implementation

2007-09-30 Thread Davide Libenzi
On Sun, 30 Sep 2007, Denys Vlasenko wrote: Hi Ulrich, On Friday 28 September 2007 18:34, Ulrich Drepper wrote: One more small change to extend the availability of creation of file descriptors with FD_CLOEXEC set. Adding a new command to fcntl() requires no new system call and the

Re: F_DUPFD_CLOEXEC implementation

2007-09-30 Thread Davide Libenzi
On Mon, 1 Oct 2007, Denys Vlasenko wrote: My use case is: I want to do a nonblocking read on descriptor 0 (stdin). It may be a pipe or a socket. There may be other processes which share this descriptor with me, I simply cannot know that. And they, too, may want to do reads on it. I want

Re: [PATCH RFC 3/9] RCU: Preemptible RCU

2007-10-01 Thread Davide Libenzi
On Sun, 30 Sep 2007, Paul E. McKenney wrote: On Sun, Sep 30, 2007 at 04:02:09PM -0700, Davide Libenzi wrote: On Sun, 30 Sep 2007, Oleg Nesterov wrote: Ah, but I asked the different question. We must see CPU 1's stores by definition, but what about CPU 0's stores (which could be seen

Re: F_DUPFD_CLOEXEC implementation

2007-10-01 Thread Davide Libenzi
On Mon, 1 Oct 2007, Denys Vlasenko wrote: On Monday 01 October 2007 19:16, Al Viro wrote: * it's on a bunch of cyclic lists. Have its neighbor go away while you are doing all that crap = boom * there's that thing call current position... It gets buggered. * overwriting it

Re: [PATCH RFC 3/9] RCU: Preemptible RCU

2007-10-01 Thread Davide Libenzi
On Mon, 1 Oct 2007, Paul E. McKenney wrote: That would indeed be one approach that CPU designers could take to avoid being careless or sadistic. ;-) That'd be the easier (unique maybe) approach too for them, from an silicon complexity POV. Distinguishing between different CPUs stores once

Re: F_DUPFD_CLOEXEC implementation

2007-10-02 Thread Davide Libenzi
On Tue, 2 Oct 2007, Denys Vlasenko wrote: I have following proposals: * make recv(..., MSG_DONTWAIT) work on any fd Sounds neat, but not trivial to implement in current kernel. This is mildly ugly, if you ask me. Those are socket functions, and the flags parameter contain some pretty

Re: [RFC + PATCH] signalfd simplification

2007-09-02 Thread Davide Libenzi
On Sun, 2 Sep 2007, Oleg Nesterov wrote: We can optimize this later, using a clever wait_queue_func_t if needed. Good idea. Will do ... - Davide - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at

Re: [PATCH] Revised timerfd() interface

2007-09-04 Thread Davide Libenzi
On Tue, 4 Sep 2007, Andrew Morton wrote: On Tue, 04 Sep 2007 10:03:56 +0200 Michael Kerrisk [EMAIL PROTECTED] wrote: Davide, Davide -- ping! Can you please offer your comments about this change, and also thoughts on Jon's and my comments about a more radical API change

Re: [PATCH] Revised timerfd() interface

2007-09-04 Thread Davide Libenzi
On Tue, 4 Sep 2007, Michael Kerrisk wrote: Hi Davide, wakes up I'd have thought that the existing stuff would be near-useless without the capabilities which you describe? Useless like it'd be a motorcycle w/out a cup-holder :) Seriously, the ability to get the previous

Re: [PATCH] Revised timerfd() interface

2007-09-04 Thread Davide Libenzi
On Tue, 4 Sep 2007, Michael Kerrisk wrote: Useless like it'd be a motorcycle w/out a cup-holder :) Seriously, the ability to get the previous values from something could have a meaning if this something is a shared global resource (like signals for example). In the timerfd case this

Re: [PATCH] Revised timerfd() interface

2007-09-05 Thread Davide Libenzi
On Wed, 5 Sep 2007, Michael Kerrisk wrote: Davide, A Michael! As I think about this more, I see more problems with your argument. timerfd needs the ability to get and get-while-setting just as much as the earlier APIs. Consider a library that creates a timerfd file descriptor

Re: [PATCH] Revised timerfd() interface

2007-09-05 Thread Davide Libenzi
On Wed, 5 Sep 2007, Michael Kerrisk wrote: Hi Davide, As I think about this more, I see more problems with your argument. timerfd needs the ability to get and get-while-setting just as much as the earlier APIs. Consider a library that creates a timerfd file descriptor

Re: [PATCH] Revised timerfd() interface

2007-09-05 Thread Davide Libenzi
On Thu, 6 Sep 2007, Michael Kerrisk wrote: Hi Davide, As I think about this more, I see more problems with your argument. timerfd needs the ability to get and get-while-setting just as much as the earlier APIs. Consider a library that creates a timerfd file

<    1   2   3   4   5   6   7   8   9   10   >