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
