This is a discussion on Re: New "timeout" api, to replace callout - FreeBSD ; In message , "Atti lio Rao" writes: >2007/12/2, Poul-Henning Kamp : >> 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 >> ...
In message <3bbf2fe10712020050p3ae55a30p84ff775dd6c103bd@mail. gmail.com>, "Atti
lio Rao" writes:
>2007/12/2, Poul-Henning Kamp
>> 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
>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.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "email@example.com"