This is a discussion on Re: New "timeout" api, to replace callout - FreeBSD ; 2007/12/2, Poul-Henning Kamp : > In message , "Atti > lio Rao" writes: > >2007/12/1, Poul-Henning Kamp : > >> > >> Here is my proposed new timeout API for 8.x. > >> > >> The primary objective is to ...
2007/12/2, Poul-Henning Kamp
> In message <3bbf2fe10712012231p2945111cma2faed2299167d3a@mail. gmail.com>, "Atti
> lio Rao" writes:
> >2007/12/1, Poul-Henning Kamp
> >> Here is my proposed new timeout API for 8.x.
> >> The primary objective is to make it possible to have multiple timeout
> >> "providers" of possibly different kind, so that we can have per-cpu
> >> or per-net-stack timeout handing.
> >I have a question so.
> I have no idea what the answer to your question is, I'm focusing on
> providing the ability, how we subsequently decide to use it is up
> to others.
Well, this is part of that too.
For things like "per-cpu" timeouts, I expect to have groups bound to
the specific CPU you referr to.
This kind of group is the only one where I can find a benefit about
having a group. I'm not sure what would one expect by having, for
example, a tcp-stack group as the generic implementation cannot do
optimization on scheduling SWIs.
What I'm trying to say is that the 'group' concept is good as an
abstraction, but I still can't see what it can bring to us. What
really matters about timeouts in SMP systems is how you expolit CPU
affinity and how you balance timeouts between them. Doing this on a
per-group basis is neither efficient or helpful really as these
details should be decided on the consumers side of the matter.
Peace can only be achieved by understanding - A. Einstein
email@example.com mailing list
To unsubscribe, send any mail to "firstname.lastname@example.org"