Hi, On Mon, 2003-10-13 at 09:37, Robert Collins wrote: > On Sat, 2003-10-11 at 06:30, Gonzalo Arana wrote: > > Hi, > > > > (I'm back to squid-gzip task now). > > I come up to this situation: > > > > squid 3.0-PRE3-20031008 with epoll > > kernel 2.4.21 patched with > > http://www.xmailserver.org/linux-patches/epoll-lt-2.4.21-0.18.diff > > > > When a client requests a very long object (such as a video), squid uses > > 100% of CPU. > > > > It was caused because epoll_wait returned immediately reporting that > > connection to client can be written without blocking. > > > > So squid was continously calling to epoll_wait, which in turn returned > > immediately. > > This is something I was about to look into. Thank you.
I'm glad I can help > > Two things: > 1) why the change to COMM_TIMEOUT as the return value? That seems > unrelated to the issue. It is true that it does not fix the problem, but I think it is more appropiate to return COMM_TIMEOUT if no file descriptor had any activity after timeout specified (comm_poll.cc returns COMM_TIMEOUT in comm_select if this happends -unless I am wrong-). > 2) Perhaps we should set the epoll to edge triggered, which IIRC was the > default in the early epoll API (and is not now ?) mmm... that would require (I think) to read/write repeatedly until EAGAIN is returned (non-blocking i/o). I will submit my suggested patch to bugzilla (Reuben Farrelly had reported this problem). Hope it helps, > > Cheers, > Rob -- Gonzalo Arana <[EMAIL PROTECTED]> UOL-Sinectis S.A.
