Re: callout patch - make callouts per-cpu and MP safe.

[Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>]

On Tue, Sep 14, 2004 at 09:39:11AM -0700, Matthew Dillon wrote:
> 
> :On Mon, Sep 13, 2004 at 10:53:13PM -0700, Matthew Dillon wrote:
> :>     This patch makes the kernel callout_*() interface per-cpu and MP safe.
> :>     Individual callouts may also be registered as MP safe or not via a second
> :>     argument to callout_reset() (using the same API a FreeBSD-5).
> :
> :I never liked the additional argument in FreeBSD-5, but I guess it can't be
> :avoided for SMP safety. Does it imply that a MP-safe callout always runs on
> :the CPU it was initially registered on? Have you looked at the timeout API
> :from NetBSD/OpenBSD, they bind e.g. the function at init time. This might
> :be more appropiate on this case.
> 
>     Well, except init time is usually in the startup code which is running
>     on only one cpu.  I'm binding the cpu when the timeout is actually 
>     started, in callout_reset().  We should probably have another API
>     call to specify the cpu, e.g. callout_reset_oncpu(), for those
>     subsystems which want to start their timeouts in the initialization
>     code.

I'm asking because I don't think the callout_reset arguments which specify
the target function and argument over and over again are the normal usage
case. I'm not 100% sure of all uses, but e.g. for the NICs the arguments
are always static.

Have a look at OpenBSD's sys/timeout.h, they have timeout_set,
timeout_add and timeout_del. 

timeout_set gets the function and data parameter, timeout_add only the
wanted delay. It's simpler to use because you don't have to worry about
thos two all over the place.

Both provide the same functionality and could be implemented in parallel,
sure. But we could avoid having to change the existing API and could
convert them on a case-by-case base.

Joerg