This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
RE: FW: locking timeout error ?
- From: "Stone, Joshua I" <joshua dot i dot stone at intel dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: <systemtap at sources dot redhat dot com>
- Date: Thu, 19 Jan 2006 14:34:39 -0800
- Subject: RE: FW: locking timeout error ?
Frank Ch. Eigler wrote:
>> [...] Imagine the performance if the probe handles perhaps 5
>> different locks in its body, which is well within reason.
>
> If the locking scheme is reorganized as outlined in #2060, by pulling
> all lock/unlock operations to the outermost level of a probe, then the
> overall (rather than per-lock) timeout could be easily bounded. Plus
> each global variable would be locked at most once per probe handler
> run, rather than around each appearance in an expression.
I really like this idea, because it treats probes as truly atomic - if
you don't get all of the locks you need, don't do anything.
Implementing this will also require full function analysis to propogate
the locks back to the probe.
> Actually, even without that, we could accumulate locking iteration
> counts in a new context variable, and limit the cumulative (rather
> than individual) total to MAXTRYLOCK.
I think this would be a much more meaningful metric, and it should be an
easy thing to implement...
Josh