Optimization opportunity: don't recurse callout mutex in timeout_reset()

[Robert Watson]

I'm currently walking our somewhat overburdened interrupt path handling
for network packets looking for optimization opportunities.  The good (and
bad) news is that there are a lot.  I'll be sending out some e-mail with
some of them.  Here's the first.  I've sent it to Colin but CC'd current@
because Colin has expressed interest in the callout code previously :-).

timeout_reset() is called from the TCP code pretty frequently.  I observed
that the callout code path is recursing the callout mutex.  Here's the KTR
trace:

 12053   0              596 LOCK (spin mutex) callout r = 0 at
../../../kern/kern_timeout.c:488                 callout_reset().
 12054   0             1056 LOCK (spin mutex) callout r = 1 at
../../../kern/kern_timeout.c:525
 12055   0              580 UNLOCK (spin mutex) callout r = 1 at
../../../kern/kern_timeout.c:562
 12056   0            17320 UNLOCK (spin mutex) callout r = 0 at
../../../kern/kern_timeout.c:515

The line numbers are off because they're from the rwatson_netperf branch,
which includes tracing and profiling for callouts.  The translation to CVS
locations is that :488 is the spin lock acquire in callout_reset(), :525
is the spin lock acquire in _callout_stop_safe(), :562 is the spin lock
drop in _callout_stop_safe(), and :515 is the spin lock drop in
callout_reset().

Eliminating the recursion would be beneficial, if we could.

Thanks!

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Principal Research Scientist, McAfee Research