poll vs. epoll

[Shachar Shemesh]

Hi all,

I have a program (a server) that has a very large number of 
synchronization constructs. Even when everything is idle there, 
wineserver is taking 60% of the CPU, raising load average to 2.4. When 
load is applied, response time occasionally jumps from tenths of a 
second to two minutes.

I noticed that in server/fd.c, the wineserver is using "poll" to select 
between file descriptors. The application is going through this code 
over 2000 times a second, with over 380 file descriptors each time. I am 
wondering whether this can be the cause of the slowdown.

One of the possible solutions to this would be to use epoll instead. 
This, of course, would have to be backed by a configure check, as not 
all systems for which wine is intended support epoll. Another, arguably 
better, solution would be to use libevent for this purpose. Libevent has 
the distinct advantage that it automatically chooses the best tool for 
the job (epoll, poll, /dev/poll, or if all else fails, select). However, 
if there is another, independent use of poll, porting the semantics to 
libevent may prove non-trivial.

So what does the forum think?

One last question. What are the "users"? What constructs cause a new 
file descriptor to be allocated in the wineserver?

Shachar

[Mike Hearn]

On Thu, 19 Aug 2004 22:16:36 +0300, Shachar Shemesh wrote:
> One last question. What are the "users"? What constructs cause a new 
> file descriptor to be allocated in the wineserver?

Every thread in every client has 3 fds: command, reply, wait. Other fds
are allocated as well I think for things like open files, but I'm not sure
of the details. I know that when I hit these sorts of problems it was due
to the large number of threads blowing the fd limit (there were lots of
sockets as well).