Re: 2.5 profiling

On Thursday 22 November 2001 09.26, Venkateswaran Govindasamy wrote:

> I am just curious to share some views on this
> discussion. As previously said, madhav and myself are
> doing eventio stuff now. It is going smoothly.

Care to commit your changes so we other can see how you are doing, and
perhaps help? The idea of devel.squid-cache.org is to open up the
development, allowing developers to more easily cooperate on the same task.
It does not matter that much if you some times break stuff in the CVS branch
as it is a development branch..

As I have not seen or heard anything from you for quite some time I sort of
assumed you had moved on to something else...

I was reviewing parts of eventio on my way home yesterday (missed the train,
giving me 30 minutes to kill), and it is quite likely I will make a small
redesign of how writes are managed on TCP connections. Had forgot to
implement the basic design ideas of eventio to the eventio interface itself,
most notably on writes..

The implementation of SSL has also shown some new requirements on event
models from layering filedescriptors that may require some minor changes. Not
yet sure what changes is actually required.. it seems the eventio model as it
is maybe addresses these new concerns in a very clean manner.

> Can you throw some views on how much % of cpu we can
> save once it is finished successfully?

Depends on what level you consider as finished.

It is quite hard to give you a view, but hopefully the change will be
substantial. The current I/O model does quite many "stupid" things which the
eventio model more or less eleminates, but some of the "stupid" things will
need to be slightly rewritten to fit the eventio model in a clean manner
before eventio can perform it's best.. Examples of such things are how delay
pools integrate with the connections.

> Henrik said previously that linux kernel has some bugs
> in RT signal. A person who has been working on RT
> signals says 2.4.13 kernel is okay for production.

Maybe. Was some versions ago since I looked at it.

The main flaw with RT signals was that they indicated too many events
depending on the packet patterns. For example if you received 10 packets
carrying 1 byte each while being buzy on some other task, RT delivered 10
read events for the connection. Obviously the data is fully read on the first
event, requiring you to deal with 9 additonal events of no interest.

In other words, the RT signals have a design flaw in that they indicate
individual data events rather than socket state events. RT would be
wounderful if it could be restricted to socket state events like

  * There is now data in the receive buffer. Only signalled if the receive
buffer was previously drained.

  * The transmit buffer has dropped below a certain threshold, for example
30%. Telling the application that it is a good idea to refill the TCP buffer
with more data if available.

  * The transmit buffer is drained

  * Connection have been closed / shutdown()

and if it would batch together connection request events (accepted
connections), rather than sending a single event per connection request.

The RT event queue is limited in size (resides in kernel memory), and it is a
waste to have to process non-interesting events.

For reading, only the buffer state changes are interesting, not packets. Whe
application needs to be able to deal with data received both as a 64 KB
packet and 64K 1 bytes packets in a similar manner. The ways RT is/was
designed does not allow for this in a clean manner.

Regards
Henrik
Received on Thu Nov 22 2001 - 02:13:55 MST