New "timeout" api, to replace callout

[Robert Watson]

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 
overhead).

Robert N M Watson
Computer Laboratory
University of Cambridge