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: Fri, 13 Jan 2006 00:04:49 -0800
- Subject: RE: FW: locking timeout error ?
Frank Ch. Eigler wrote:
>> Actually, I meant to ask you about this. Is it safe to be waiting so
>> long for a lock if the probe is in interrupt context? If I
>> understand it, the lock will wait about MAXTRYLOCK*TRYLOCKDELAY
>> nanoseconds = 100 microseconds. That seems like an awfully long
>> time to poll the lock.
>
> The current figures are not meant as definitive. It may be wise to
> wait less if in_interrupt(). Do you have alternate numbers to
> suggest?
I'll leave it to the experts to decide what is appropriate. But even
when not in_interrupt, I think this may be too long. Do we have
estimates for what a "reasonable" runtime for a probe? We can assume
that in the worst case, the lock will almost timeout everytime, but
still succeed. Imagine the performance if the probe handles perhaps 5
different locks in its body, which is well within reason.
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?
Josh