* Borislav Petkov wrote:
> > > A problem here is that mmap'ed buffer size (number of pages) must be
> > > be equal to the pre-existing buffer size and thus to be known
> > > somehow.
> >
> > What about also exporting the buffer size via sysfs pmu directory?
>
> Yes, we've been discussing buf
On Thu, Jun 27, 2013 at 02:46:36PM +0900, Namhyung Kim wrote:
> How about using 2 bits for perfsistent flag, 1 for connecting to an
> existing one, 2 for creating new one.
No need since persistent events don't need to be duplicated. Think of a
tracepoint: the samples you get there are the same, no
Hi Robert,
On Wed, 26 Jun 2013 14:44:24 +0200, Robert Richter wrote:
> On 26.06.13 13:45:38, Ingo Molnar wrote:
>> [ How about to additional logic: attr.persistent=1 && attr.config==0 means
>> a new persistent event is created straight away - no ioctl is needed to
>> detach it explicitly. ]
On 26.06.13 13:45:38, Ingo Molnar wrote:
> * Robert Richter wrote:
> > Creating a persistent event from userspace:
> >
> > * A process opens a system-wide event with the syscall and gets a fd.
>
> Should this really be limited to system-wide events?
It must not necessarily be restricted to sys
* Ingo Molnar wrote:
> Note, for tracing the PERF_FLAG_FD_OUTPUT method of multiplexing
> multiple events onto a single mmap buffers is probably useful (also
> usable via the PERF_EVENT_IOC_SET_OUTPUT ioctl()), so please make sure
> the scheme works naturally with that model as well, not just
* Robert Richter wrote:
> On 26.06.13 10:24:08, Borislav Petkov wrote:
> > On Wed, Jun 26, 2013 at 10:12:23AM +0200, Robert Richter wrote:
> > > We get a new fd by opening the persistent event with the syscall.
> > > There would be 2 new ioctls:
> > >
> > > ioctl(fd, PERF_EVENT_IOC_DETACH, 0);
On 26.06.13 10:24:08, Borislav Petkov wrote:
> On Wed, Jun 26, 2013 at 10:12:23AM +0200, Robert Richter wrote:
> > We get a new fd by opening the persistent event with the syscall.
> > There would be 2 new ioctls:
> >
> > ioctl(fd, PERF_EVENT_IOC_DETACH, 0);
> > ioctl(fd, PERF_EVENT_IOC_ATTACH,
On Wed, Jun 26, 2013 at 11:46:34AM +0200, Ingo Molnar wrote:
> If already existing persistent events show up somewhere in sysfs
> (or in a separate pseudofilesystem) then an open() of them [given
> sufficient privileges of the caller, etc.] could attach to them.
Yep, I think we want to say sys_per
* Borislav Petkov wrote:
> On Wed, Jun 26, 2013 at 10:12:23AM +0200, Robert Richter wrote:
> > We get a new fd by opening the persistent event with the syscall.
> > There would be 2 new ioctls:
> >
> > ioctl(fd, PERF_EVENT_IOC_DETACH, 0);
> > ioctl(fd, PERF_EVENT_IOC_ATTACH, 0);
> >
> > This
On Wed, Jun 26, 2013 at 10:12:23AM +0200, Robert Richter wrote:
> We get a new fd by opening the persistent event with the syscall.
> There would be 2 new ioctls:
>
> ioctl(fd, PERF_EVENT_IOC_DETACH, 0);
> ioctl(fd, PERF_EVENT_IOC_ATTACH, 0);
>
> This would be fine and reuses existing infrastru
On 25.06.13 21:16:54, Borislav Petkov wrote:
> On Tue, Jun 25, 2013 at 07:57:29PM +0200, Robert Richter wrote:
> > But what options there are to detach the event from all processes and
> > make it persistent?
>
> Something like this:
>
> ioctl(fd, PERF_EVENT_IOC_DETACH, 0);
>
> I guess thi
On Tue, Jun 25, 2013 at 07:57:29PM +0200, Robert Richter wrote:
> But what options there are to detach the event from all processes and
> make it persistent?
Something like this:
ioctl(fd, PERF_EVENT_IOC_DETACH, 0);
I guess this could simply set the persistent flag so that the rest of
th
On 24.06.13 21:45:11, Ingo Molnar wrote:
>
> * Peter Zijlstra wrote:
>
> > Oh and what Boris and Ingo said; persistent events should 'persist' and
> > not be tied to particular processes.
Fine with me too. But we need an answer how to create/release
persistent events.
It's easy to add them as
On 24.06.13 12:22:00, Peter Zijlstra wrote:
> On Tue, Jun 11, 2013 at 06:42:26PM +0200, Robert Richter wrote:
> > Note that perf tools need to support the 'attr' syntax that is
> > added in a separate patch set. With it we are able to run perf tool
> > commands to read persistent events, e.g.:
>
>
On 24.06.13 12:08:19, Peter Zijlstra wrote:
> > git://git.kernel.org/pub/scm/linux/kernel/git/rric/oprofile.git
> > persistent-v2
> >
>
> OK, so I gave up on reading the patches :/ and went and looked at the git
> tree. There's just too much needless churn in the patches.
Ok, we will rework th
* Peter Zijlstra wrote:
> On Tue, Jun 11, 2013 at 06:42:26PM +0200, Robert Richter wrote:
>
> Oh and what Boris and Ingo said; persistent events should 'persist' and
> not be tied to particular processes. I'm not sure about the entire
> eventfs thing; but the proposed sysfs thing should definit
On Tue, Jun 11, 2013 at 06:42:26PM +0200, Robert Richter wrote:
Oh and what Boris and Ingo said; persistent events should 'persist' and
not be tied to particular processes. I'm not sure about the entire
eventfs thing; but the proposed sysfs thing should definitely work for
now.
--
To unsubscribe f
On Tue, Jun 11, 2013 at 06:42:26PM +0200, Robert Richter wrote:
> The basic concept is to use a pmu as an event container for persistent
> events. The pmu registers events in sysfs and provides format and
> event information for the userland. The persistent event framework
> requires to add events
On Tue, Jun 11, 2013 at 06:42:26PM +0200, Robert Richter wrote:
> Note that perf tools need to support the 'attr' syntax that is
> added in a separate patch set. With it we are able to run perf tool
> commands to read persistent events, e.g.:
where is this patch? I can't find it.
I also find attr
On Tue, Jun 11, 2013 at 06:42:26PM +0200, Robert Richter wrote:
> This patch set implements out of the box support of perf tools for
> persistent events. For this the kernel must provide necessary
> information about existing persistent events via sysfs to userland.
> Persistent events are provided
20 matches
Mail list logo
