Re: 2.5 profiling

--- Henrik Nordstrom <hno@squid-cache.org> wrote:
> 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..
>

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.

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

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

>
> > 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.
>
Yes

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

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

Regards,
Venkatesh

__________________________________________________
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1
Received on Thu Nov 22 2001 - 10:52:26 MST