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

Joerg Sonnenberger joerg at britannica.bec.de
Tue Sep 14 05:41:22 PDT 2004


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.

>     I would appreciate more widespread testing before I commit it.  I did 
>     some simple testing on a UP and SMP box but the API is used all over the
>     system so prudence is required :-)
> 
> 	fetch http://leaf.dragonflybsd.org/~dillon/callout01.patch

I'll check this patch, of course :)

>     There is plenty of further work on the timeout_*() interface that can 
>     be done.   I would dearly love to replace the old timeout() and 
>     untimeout() functions with the newer callout_init()/callout_reset() API,
>     because that will free up 800KB+ of wired physical memory and allow us
>     to remove a ton of cruft from kern_timeout.c.  The old routines are used
>     all over the kernel but any developer who wants to have a go at it please
>     do!  Submit patches one device at a time, though, and test that the
>     kernel compiles and boots before you submit (The patches are also going
>     to require very careful review once submitted).
> 
>     Any takers?

I've been working on this already for dev/netif whenever I did greater changes
to a driver. I've been working on other parts of the code base. If someone
wants to submit patches, I'd like to coordinate this effort off-list.

Joerg

> 					-Matt
> 					Matthew Dillon 
> 					<dillon at xxxxxxxxxxxxx>





More information about the Kernel mailing list