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
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.
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"