| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <48FF49BD.8000608@gmail.com> Date: Wed, 22 Oct 2008 18:41:49 +0300 From: Török Edwin <edwintorok@...il.com> To: Ingo Molnar <mingo@...e.hu> CC: Peter Zijlstra <a.p.zijlstra@...llo.nl>, sandmann@...mi.au.dk, linux-kernel@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>, Arjan van de Ven <arjan@...radead.org> Subject: Re: [PATCH 4/4] Implement semaphore latency tracer On 2008-10-22 18:28, Ingo Molnar wrote: > hm, but the most common synchronization primitive are mutexes - and > those are not covered by your patchset. > Indeed. I've seen a patch from Jason Baron to introduce tracepoints for mutexes, but the conclusion was that the tracepoints should be in lockstat instead. And if lockstat is enabled Peter Zijlstra's 'contend with points' patch seems to do exactly what I want to. However I think it would be useful to have (a tracepoints based?) latency tracker, which can be enabled/disabled at runtime, and which doesn't add any data to the mutex/semaphore structures. My patchset was a first attempt towards that, but it seems that such use of tracepoints is not welcome at this time? Please tell me if I should continue working on this, or if I my patches are designed totally on the wrong way. Best regards, --Edwin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists