Re: 2.5 profiling

Venkateswaran Govindasamy wrote:

> We have made some changes in the design also. After
> having discussion with madhav, We will let you know
> about when we send the code and design document. More
> or less we are near to finish eventio without SSL,
> delay_pools and Disk.

Great!

> If you have more design ideas other than
> devel.squid-cache.org website, you can send us now.

There is also the long term goal that the reference counted buffers
returned by eventio is to be reused for the whole duration of that data,
with as little data copying as possible, unless if the data needs to be
modified. I.e. a data buffer returned by eventio is sent to both the
store and the requestor. When all are done with the data it will be
freed.

> I think signal-per-fd would partially solve this
> problem, As it is only allowing one event per fd at
> any point of time.

Not familiar with the "signal-per-fd" concept. Please expand or provide
a reference.

What I tried to outline was not only the excessive amount of
notifications RT can deliver, but also when it delivers an event. Many
of the events it delivers are of very low value. It sould concentrate on
delivering the events that bring value to the application, not caring
too much about the detailed progress.

For example, read events. It is sufficient to signal once there is data
available on a FD. Signaling an event again only because there now is
MORE data on the same FD is more or less worhless.

Similarily for writes, except that there is need of a hig/low water mark
events to let the application refill the TCP buffer.

From reading the kernel source I saw that there was some filtering like
this, but obviously not sufficient. Maybe this has been improved since
then. Needs to be tested.

Regards
Henrik
Received on Thu Nov 22 2001 - 12:39:28 MST