On Thu, Mar 29, 2012 at 06:32:22PM +0200, Hagen Paul Pfeifer wrote: > * Jason Baron | 2012-03-29 11:53:24 [-0400]: > > >I was trying to better understand the use-case, since at least for the > >test case you posted, 'EPOLLET', already does what you want. > > > >Also, the 'EPOLLEXCLUSIVE' flag in your patch addresses multiple threads > >blocking on *different* epoll fds. However, if multiple threads are > >blocked on a single epoll fd, they will all be woken even if 'EPOLLEXCLUSIVE' > >is set. Shouldn't 'EPOLLEXCLUSIVE' affect that case too? > > Hey Jason, > > I just wanted to address the "main use-case" (as implemented in a bunch of > network server): one listen socket (say 80) is created and a epoll fd is > created. The listen socket is added to the set and n threads are created > afterwards. So now you have the situation that one listening socket is added > to the set and all threads are awoken if a new client connects. This patch > reduce the useless-all-thread-awoken-overhead by awake only one thread. > > Hagen Hi, But the behavior of the testcase you've supplied is not changed by the 'EPOLLEXCLUSIVE' support. So is this not the right testcase? Thanks, -Jason -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
