[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120329163222.GA3145@hell>
Date: Thu, 29 Mar 2012 18:32:22 +0200
From: Hagen Paul Pfeifer <hagen@...u.net>
To: Jason Baron <jbaron@...hat.com>
Cc: richard -rw- weinberger <richard.weinberger@...il.com>,
torvalds@...ux-foundation.org, LKML <linux-kernel@...r.kernel.org>,
Al Viro <viro@...iv.linux.org.uk>,
Lucas De Marchi <lucas.demarchi@...fusion.mobi>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-fsdevel@...r.kernel.org, eric.dumazet@...il.com
Subject: Re: [PATCH Resend] epoll: add EPOLLEXCLUSIVE support
* 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists