On Sun, 2 Dec 2007, Poul-Henning Kamp wrote:

> I guess I need to elaborate that point some more:
> If we want CPU affinity, what happens that that we pass a per-cpu timeout
> provider:
> timeout_init(&pcpu->timouts, ...)
> If we want a private timeout group for NFS we pass that in:
> timeout_init(&nfs_timeouts, ...)
> Think of the implmentation of the timeouts as an object of which we can have
> multiple instances with various private properties...

The reason affinity is getting raised in particular is that quite a few people
are running around thinking that affinity is something that they do want and
plan to use. In the above, affinity is a property of the consumer in the
event that the consumer has its own timeout instance. If it's a common
property across many consmers, it's not something we want every consumer to
deal with as it adds a significant degree of complexity to each consumer.
I.e., rather than nfs_timeouts, it's pcpu.nfs_timeouts, or nfs_timeouts[cpu],
leading to every consumer defining MAXCPUs or a related constant instances
instead of a single instance that knows about affinity. Also, if there are
multiple instances, that means "migrating" a callout from one CPU to another
involves moving it from one instance to another, rather than simply asking the
instance to move it in the way it understands best (which might involve less

Robert N M Watson
Computer Laboratory
University of Cambridge
freebsd-arch@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"