Date: Wed, 4 Aug 2004 23:28:07 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: cperciva@FreeBSD.org Cc: current@FreeBSD.org Subject: Optimization opportunity: don't recurse callout mutex in timeout_reset() Message-ID: <Pine.NEB.3.96L.1040804232402.19039I-100000@fledge.watson.org>
next in thread | raw e-mail | index | archive | help
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@fledge.watson.org Principal Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040804232402.19039I-100000>