Re: [PATCH] Hot idle

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Wed, 30 Oct 2013 17:52:57 -0600

On 10/01/2013 06:08 PM, Amos Jeffries wrote:
> On 2/10/2013 12:59 p.m., Alex Rousskov wrote:
>> On 09/12/2013 10:48 AM, Alex Rousskov wrote:
>>> The only potentially bad side effect of this change I can think of is
>>> that some events will be scheduled and fired a few microseconds before
>>> they are due (instead of a few microseconds after they are due). I hope
>>> that would not break any existing Squid code. If it does, we can adjust
>>> EventSchedule to round up and, hence, fire all events at or after their
>>> deadline.

>> I am still concerned about this, even though I do not know of any
>> specific cases where firing events a little earlier would break things.
>> It just feels wrong, and I know that libevent or libev specifically
>> avoids firing events early. Should we change this before the patch is
>> committed? Or just keep the code simple[r] until we know a change is
>> needed?
>>
>> To change this, we would need to introduce a minimum I/O wait time (X),
>> essentially: If some events will become ready to fire in less than X
>> milliseconds (but are not yet ready now), Squid would still wait for I/O
>> at most X milliseconds. I suggest setting X to 0.1 millisecond. Any
>> better ideas?

> Nope. Sounds good.
>
> There is no guarantee for any event that it will be run within the same
> millisecond (or even same whole second) than which it was scheduled due
> to already queued events or Calls taking up time. So adding an explicit
> delay will not hurt (much).

The attached revised patch honors the "no event fired before it is due"
guarantee.

Thank you,

Alex.
P.S. Despite all these changes, idle Squid still runs hotter than it
should because the maximum waiting time is artificially capped outside
the event queue to one second (EVENT_LOOP_TIMEOUT). This causes at most
one extra loop iteration per second (because the external cap overwrites
the careful math done inside the new code). This remaining problem is
outside this project scope. IIRC, the artificial 1s cap is due to some
delay pools code (that should be using regular timed events instead of
this hard-coded 1s hack, I guess).

Received on Wed Oct 30 2013 - 23:53:09 MDT

This archive was generated by hypermail 2.2.0 : Thu Oct 31 2013 - 12:00:17 MDT