Messages in this thread | | | Date | Fri, 9 May 2014 11:17:53 +0200 | From | Robert Richter <> | Subject | Re: [PATCH v4 00/16] perf, persistent: Add persistent events |
| |
On 08.05.14 20:23:44, Borislav Petkov wrote: > On Wed, May 07, 2014 at 06:44:07PM +0200, Robert Richter wrote: > > With transparently I mean that the process even does not know that the > > same event is already running by another process. The kernel detects > > this and maps the request to that event and buffer. Of course the > > event's buffer must be at least readonly to be shared for this. > > Yes. > > > This could be a mechanism to connect to persistent events. The kernel > > detects by type and attr that the requested event is already running > > persistent and maps to it. > > > > But at the moment persistent events can only be shared using > > > > attr.type = PERF_TYPE_PERSISTENT > > attr.config = id > > > > So the above is more an alternative to connect to persistent events > > and the question is, which one to use. Presumable the easiest first, > > which is the current implementation. > > Well, there is no trivial way to share event buffers if they're not > read-only AFAICT. > > But in questions like this, we always have to step one step back and ask > ourselves: what are the use cases for shared events and after we have > enumerated them, to design the kernel side so that it supports them. > > So, do we want anything else besides shared, read-only events?
I only talk about events that are sharable since they are read-only.
The question I am asking here is how to connect to an event that is sharable. This could be done transparently.
-Robert
| |