| 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
| ||
|
Date: Thu, 29 May 2008 14:03:06 -0500 From: Jason Yeh <jason.yeh@....com> To: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca> CC: linux-kernel@...r.kernel.org Subject: Re: [RFC][Patch 1/1] Oprofile Multiplexing Mathieu Desnoyers wrote: > > I have been contemplating the idea of using the performance counters in > the LTTng kernel tracer for quite a while, but I see the the underlying > implementations often deal with those counters as if they were > per-process ressources. Given those ressources are limited amongst the > whole system, would it make sense to allow an in-kernel consumer to > connect to some of these counters on a per-CPU basis and return a > "ressource not available error" to userspace when it tries to connect to > them ? (and also to kick out a userspace reader when an higher priority > in-kernel request is done, which implies that the "read" operation may > fail) > Mathieu, It sounds like you are asking a re-design of the current Oprofile. I agree with you that some sort of abstraction are needed for arbitrate who get to connect the counters. This is probably part of the objectives of the Perfmon2 guys working toward. The patch is aimed to provide a quick way based on the current implementation to be able to profile more events than the number of hardware counters. Jason -- 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