Re: squid-3.0-PRE3-20031008 w epoll bug?

From: David Nicklay <>
Date: Wed, 15 Oct 2003 13:54:52 -0400


I tested your patch, but so far at least I don't see it doing anything
for my CPU load. I tested this by using wget to fetch a 64 Megabyte
file and pausing the download midway through. squid still kept on using
100% CPU no matter how long I paused the download. It didn't go down
until I outright killed wget.

I have been looking at this in a little more detail now. Currently, I
am using read_handler and write_handler as variables to make decisions
about what epoll is interested in inside of the kernel. Now I can see
that this is not a good way to do things, because these do not always
jive with what the kernel epoll has.

Unfortunately, the reason I did it this way to start with was because
epoll does not have a function to query what a file descriptor is
interested in (I need to send a note to the author of epoll about this).
  In the meantime what I am going to have to do to make all of this work
correctly is find a place to store an extra variable or two in which I
can store what epoll actually has (kludge kludge kludge).

Anyone have a better way to do this?

Gonzalo Arana wrote:
> Hi,
> On Mon, 2003-10-13 at 09:37, Robert Collins wrote:
>>On Sat, 2003-10-11 at 06:30, Gonzalo Arana wrote:
>>>(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
>>>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
>>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 ( 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,

David Nicklay
Location: CNN Center - SE0811A
Office: 404-827-2698	Cell: 404-545-6218
Received on Wed Oct 15 2003 - 11:54:54 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:20:44 MST