Date: Sun, 2 Dec 2007 09:50:12 +0100 From: "Attilio Rao" <attilio@freebsd.org> To: "Poul-Henning Kamp" <phk@phk.freebsd.dk> Cc: arch@freebsd.org Subject: Re: New "timeout" api, to replace callout Message-ID: <3bbf2fe10712020050p3ae55a30p84ff775dd6c103bd@mail.gmail.com> In-Reply-To: <17366.1196583284@critter.freebsd.dk> References: <3bbf2fe10712012231p2945111cma2faed2299167d3a@mail.gmail.com> <17366.1196583284@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
2007/12/2, Poul-Henning Kamp <phk@phk.freebsd.dk>: > In message <3bbf2fe10712012231p2945111cma2faed2299167d3a@mail.gmail.com>, "Atti > lio Rao" writes: > >2007/12/1, Poul-Henning Kamp <phk@phk.freebsd.dk>: > >> > >> 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. Attilio -- Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe10712020050p3ae55a30p84ff775dd6c103bd>