New "timeout" api, to replace callout

[Poul-Henning Kamp]

In message <3bbf2fe10712020050p3ae55a30p84ff775dd6c103bd at mail.gmail.com>, "Atti
lio Rao" writes:
>2007/12/2, Poul-Henning Kamp <phk at 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 at 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.