lkml.org 
[lkml]   [2000]   [Feb]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subject[PATCH] spinlock metering (2.3.42)

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[unhandled content-type:application/octet-stream]
\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.202 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site