Messages in this thread | | | Date | Wed, 22 Oct 2008 17:28:42 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH 4/4] Implement semaphore latency tracer |
| |
* Török Edwin <edwintorok@gmail.com> wrote:
> On 2008-10-12 22:13, Peter Zijlstra wrote: > > On Sun, 2008-10-12 at 16:12 +0300, Török Edwin wrote: > > > >> Each time a down_read or down_write fails, a unique latency id is generated. > >> Later when someone releases the semaphore, it is blamed for the latency of all > >> tasks on the wait_list of the semaphore. > >> If you would group the output from latency_trace by the latency_id you get all those > >> who were contending on a lock, and the tasks that were holding the lock. > >> An entry in latency_trace has the format: > >> (latency_id) [semaphore_id] read|write > >> stacktrace <= stacktrace > >> > > > > What can this tracer do that latencytop cannot already do? > > Latencytop can show latencies in down_read or down_write (and is very > useful at doing that), but it cannot show who else was holding the > semaphore, > i.e. the true cause of the latency. > > Consider: > process A holds a semaphore for reading, process B tries to acquire it > for writing and fails. Latencytop shows the latency in process B, but > doesn't > show anything about process A. > > The semlat tracer is doing something more similar to lockstat, but > doesn't need lockdep, and it adds tracepoints on the slowpath only (lock > failed, wakeup).
hm, but the most common synchronization primitive are mutexes - and those are not covered by your patchset.
Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |