linux-kernel - Re: [RFC][Patch 1/1] Oprofile Multiplexing

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <483EFDEA.3010003@amd.com>
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/