Please consider this SMP i386 patch against 2.3.42 to add a "spinlock
metering"
enhancement. This patch is also found at:
http://oss.sgi.com/projects/lockmeter/download/
This patch also provides tentative support for lockmetering of Alpha
kernels,
though this work should be considered "in progress". An earlier version
of
the patch, prior to some restructuring, did compile and execute on
Alpha.
Spinlock metering is the runtime recording of data about spinlock usage
-- how often each spinlock is acquired by each locker and held for how long, how often an acquisition attempt faced contention and had to wait because someone else owned that spinlock, and how much wait-time passed before the lock was released and the contention went away.The new functionality exists in two 10KB gzip'ed pieces of code: a kernel patch containing two new files and several modified files; and a new "lockstat" command, which turns the functional act of metering on or off in a metering-capable kernel, and which retrieves the kernel's metering data and displays it to the user in a human-readable tabular format. The "lockstat" command source code can be found at the above URL.
Lockstat uses the running kernel's System.map to translate the kernel's reported virtual addresses into symbolic spinlock and procedure names, whenever possible. Wait-times and hold-times are displayed in microseconds.
After the kernel patch is applied to the kernel, a new config variable (in the "Kernel hacking" subsection) controls whether or not metering gets compiled into the kernel. A metering-capable kernel has essentially the same size as a non-metering-capable kernel because the non-metered kernel's inline locking code gets replaced by procedure calls, and the multiple-reader-single-writer locks get significantly smaller.
A metering-capable kernel is negligibly slower than a normal kernel when metering is turned off. It is 1-2% slower when default metering is turned on, recording wait-times, and it is as much as 5-8% slower when the optional "hold-time" metering functionality is turned on. Thus, wait-time metering is negligibly invasive to system performance and provides a black-box look at which locks (and their callers) produce the longest contending waits, and hold-time metering provides a more illuminating look at which callers are actually holding these locks and for how long -- more interesting information for the analyst, but at the higher cost of degraded kernel performance.
Care has been taken to minimize runtime performance impact of lockmetering. For example, the data structures that record the counts and times are separated per CPU, which means there is no cache coherency overhead when different CPUs update counts for the same spinlock being called by the same caller.
-- John Hawkes (hawkes@engr.sgi.com) http://oss.sgi.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:14 EST