Date: Sun, 02 Dec 2007 09:17:35 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: "Attilio Rao" <attilio@freebsd.org> Cc: arch@freebsd.org Subject: Re: New "timeout" api, to replace callout Message-ID: <17695.1196587055@critter.freebsd.dk> In-Reply-To: Your message of "Sun, 02 Dec 2007 09:50:12 %2B0100." <3bbf2fe10712020050p3ae55a30p84ff775dd6c103bd@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <3bbf2fe10712020050p3ae55a30p84ff775dd6c103bd@mail.gmail.com>, "Atti lio Rao" writes: >2007/12/2, Poul-Henning Kamp <phk@phk.freebsd.dk>: >> 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. There are many possibilities we need to explore, but before we can do that, we need a mechanism that allows us to have multiple timeout providers. >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. There may be locking related optimizations to be had, or they may be a wash with the ekstra overhead. Time will show. Implementation wise there is no difference between enabling per-cpu timeouts, and enabling us to have any number of timeout providers, grouped or not. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17695.1196587055>