This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: FW: locking timeout error ?


On 1/16/06, Frank Ch. Eigler <fche@redhat.com> wrote:
> Hi -
>
> > [...] 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.
>
> 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.
>
>
> > Perhaps the better way to approach this is to estimate how long we might
> > expect the person holding the lock to take.  Do we have any
> > microbenchmarks on how long various operations take, like indexing a
> > map?
>
perhaps it would be better if systemtap took no locks, other than
private ones related to systemtap data structures, sure it will be
harder to write, but you can be sure that your script will work long
term. Not having to worry about some part of the kernel taking a lock
you depend on and holding it or worse yet, taking a lock and then have
a probe fire that wants to take the lock being held.

James Dickens
uadmin.blogspot.com



> Unfortunately, no.  Bug #1884 and #2060 could benefit from the
> development of a microbenchmark suite.
>
>
> - FChE
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]