[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100701162424.GI17823@aftab>
Date: Thu, 1 Jul 2010 18:24:24 +0200
From: Borislav Petkov <bp@...64.org>
To: Frederic Weisbecker <fweisbec@...il.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
Arnaldo Carvalho de Melo <acme@...radead.org>,
Steven Rostedt <rostedt@...dmis.org>,
Ingo Molnar <mingo@...e.hu>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 03/21] perf_events: Add a helper to search for an event
in a context
From: Frederic Weisbecker <fweisbec@...il.com>
Date: Thu, Jul 01, 2010 at 12:14:50PM -0400
Hi Frederic,
> On Thu, Jul 01, 2010 at 06:12:45PM +0200, Peter Zijlstra wrote:
> > On Thu, 2010-07-01 at 18:11 +0200, Frederic Weisbecker wrote:
> > > I suspect we need another syscall that can list all the persistent events
> > > with a unique id and the attrs that follow.
> > >
> > > So you get a unique id for all of them and you can create an fd on top
> > > of this id by using a PERF_FLAG_REQUEST_PERSISTENT and this id put in
> > > attr.config.
> >
> > Isn't that what filesystems were invented for?
>
>
> The problem is when you create a persistent event, you lose the fd.
> So you need to retrieve it somehow.
actually the idea is to decouple those from the fd alltogether and
provide specific file_operations in debugfs and such, as Peter
suggested. Which sounds much more sane to me especially since, at least
in the MCE case, all the entities that register into that event need to
see the same samples (and read the same buffers etc).
And let's try not to read too much into those persistent events - it may
just as well be that we need them only for MCEs and nothing else :)
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632
--
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