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

Hi,

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:
>>
>>>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

-- 
David Nicklay
Location: CNN Center - SE0811A
Office: 404-827-2698	Cell: 404-545-6218