From: Robert Richter robert.rich...@linaro.org
The event parser is limited to update only a subset of all fields in
struct perf_event_attr (config*, period, branch_type). We are not able
to set other attr fields, esp. flags.
Introducing a new syntax to set any field of the event attribute
On 29.07.13 18:12:40, Jed Davis wrote:
> All architectures except x86 use __copy_from_user_inatomic to provide
> arch_perf_out_copy_user; like the other copy_from routines, it returns
> the number of bytes not copied. perf was expecting the number of bytes
> that had been copied. This change
On 29.07.13 18:12:40, Jed Davis wrote:
All architectures except x86 use __copy_from_user_inatomic to provide
arch_perf_out_copy_user; like the other copy_from routines, it returns
the number of bytes not copied. perf was expecting the number of bytes
that had been copied. This change
On 21.07.13 22:37:53, Will Deacon wrote:
> Ok, I think I'm with you now. I also think that a better solution would be
> to try and limit the r7/fp confusion to one place, perhaps behind something
> like:
>
> void arm_get_current_stackframe(struct pt_regs *regs, struct stackframe
> *frame);
In
On 21.07.13 22:37:53, Will Deacon wrote:
Ok, I think I'm with you now. I also think that a better solution would be
to try and limit the r7/fp confusion to one place, perhaps behind something
like:
void arm_get_current_stackframe(struct pt_regs *regs, struct stackframe
*frame);
In
Commit-ID: 4e319027a7aee58ce8d409f5597b418f08307841
Gitweb: http://git.kernel.org/tip/4e319027a7aee58ce8d409f5597b418f08307841
Author: Robert Richter
AuthorDate: Tue, 11 Jun 2013 17:29:18 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 12 Jul 2013 13:45:54 -0300
perf tools
Commit-ID: ab4ecda5205b56cb3b8b44f2c18ffdefb24313a2
Gitweb: http://git.kernel.org/tip/ab4ecda5205b56cb3b8b44f2c18ffdefb24313a2
Author: Robert Richter
AuthorDate: Tue, 16 Jul 2013 16:50:36 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 17 Jul 2013 10:40:02 -0300
perf tools
Commit-ID: ab4ecda5205b56cb3b8b44f2c18ffdefb24313a2
Gitweb: http://git.kernel.org/tip/ab4ecda5205b56cb3b8b44f2c18ffdefb24313a2
Author: Robert Richter r...@kernel.org
AuthorDate: Tue, 16 Jul 2013 16:50:36 +0200
Committer: Arnaldo Carvalho de Melo a...@redhat.com
CommitDate: Wed, 17 Jul
Commit-ID: 4e319027a7aee58ce8d409f5597b418f08307841
Gitweb: http://git.kernel.org/tip/4e319027a7aee58ce8d409f5597b418f08307841
Author: Robert Richter robert.rich...@linaro.org
AuthorDate: Tue, 11 Jun 2013 17:29:18 +0200
Committer: Arnaldo Carvalho de Melo a...@redhat.com
CommitDate: Fri
On 18.07.13 13:19:13, Arnaldo Carvalho de Melo wrote:
> Em Thu, Jul 18, 2013 at 02:19:24PM +0200, Robert Richter escreveu:
> > I noticed you applied the patch to acme/perf/core, but it should be
> > instead in urgent since mainline is broken.
>
> I did it because there
Arnaldo,
On 18.07.13 14:19:24, Robert Richter wrote:
> No issues noticed, accept that doc is built when running the 'install'
> target, not 'all'.
>
> Will look at this.
see patch below that fixes the above.
-Robert
>From 3bf424ea33526fefbce9f95d4ccfaffd36016a21 Mon Sep 1
Arnaldo,
I noticed you applied the patch to acme/perf/core, but it should be
instead in urgent since mainline is broken.
On 17.07.13 18:10:51, Robert Richter wrote:
> On 17.07.13 17:40:01, Borislav Petkov wrote:
> > On Wed, Jul 17, 2013 at 12:31:18PM -0300, Arnaldo Carvalho de M
Arnaldo,
I noticed you applied the patch to acme/perf/core, but it should be
instead in urgent since mainline is broken.
On 17.07.13 18:10:51, Robert Richter wrote:
On 17.07.13 17:40:01, Borislav Petkov wrote:
On Wed, Jul 17, 2013 at 12:31:18PM -0300, Arnaldo Carvalho de Melo wrote:
Humm
Arnaldo,
On 18.07.13 14:19:24, Robert Richter wrote:
No issues noticed, accept that doc is built when running the 'install'
target, not 'all'.
Will look at this.
see patch below that fixes the above.
-Robert
From 3bf424ea33526fefbce9f95d4ccfaffd36016a21 Mon Sep 17 00:00:00 2001
From
On 18.07.13 13:19:13, Arnaldo Carvalho de Melo wrote:
Em Thu, Jul 18, 2013 at 02:19:24PM +0200, Robert Richter escreveu:
I noticed you applied the patch to acme/perf/core, but it should be
instead in urgent since mainline is broken.
I did it because there are alternative ways to build
On 17.07.13 09:36:57, Linus Torvalds wrote:
> On Wed, Jul 17, 2013 at 9:05 AM, Robert Richter wrote:
> >
> > I narrowed this down. The problem is that zinstall on ARCH=arm has a
> > dependency to vmlinux which does a prepare/prepare3 and finally does a
> > forced reb
On 17.07.13 17:40:01, Borislav Petkov wrote:
> On Wed, Jul 17, 2013 at 12:31:18PM -0300, Arnaldo Carvalho de Melo wrote:
> > Humm, probably it will look at the top level 'install' target? There
> > was some discussion about this, right? Can you refresh my mind?
Yeah, this
make tools/perf
(trimmed cc list)
On 12.07.13 11:57:21, Robert Richter wrote:
> On 11.07.13 10:16:18, Linus Torvalds wrote:
> > On Thu, Jul 11, 2013 at 6:54 AM, Michal Marek wrote:
> > >
> > > Yeah. It also reveals another bug that we rewrite the kernel.release
> > > file
(trimmed cc list)
On 12.07.13 11:57:21, Robert Richter wrote:
On 11.07.13 10:16:18, Linus Torvalds wrote:
On Thu, Jul 11, 2013 at 6:54 AM, Michal Marek mma...@suse.cz wrote:
Yeah. It also reveals another bug that we rewrite the kernel.release
file each time.
The odd thing I have
On 17.07.13 17:40:01, Borislav Petkov wrote:
On Wed, Jul 17, 2013 at 12:31:18PM -0300, Arnaldo Carvalho de Melo wrote:
Humm, probably it will look at the top level 'install' target? There
was some discussion about this, right? Can you refresh my mind?
Yeah, this
make tools/perf install
On 17.07.13 09:36:57, Linus Torvalds wrote:
On Wed, Jul 17, 2013 at 9:05 AM, Robert Richter r...@kernel.org wrote:
I narrowed this down. The problem is that zinstall on ARCH=arm has a
dependency to vmlinux which does a prepare/prepare3 and finally does a
forced rebuild of kernel.release
On 12.07.13 10:39:09, Robert Richter wrote:
> On 12.07.13 01:49:40, tip-bot for Robert Richter wrote:
> > Commit-ID: 107de3724eff5a6fa6474a4d2aa5460b63749ebf
> > Gitweb:
> > http://git.kernel.org/tip/107de3724eff5a6fa6474a4d2aa5460b63749ebf
> > Author: Rob
On 12.07.13 10:39:09, Robert Richter wrote:
On 12.07.13 01:49:40, tip-bot for Robert Richter wrote:
Commit-ID: 107de3724eff5a6fa6474a4d2aa5460b63749ebf
Gitweb:
http://git.kernel.org/tip/107de3724eff5a6fa6474a4d2aa5460b63749ebf
Author: Robert Richter robert.rich...@linaro.org
On 11.07.13 10:16:18, Linus Torvalds wrote:
> On Thu, Jul 11, 2013 at 6:54 AM, Michal Marek wrote:
> >
> > Yeah. It also reveals another bug that we rewrite the kernel.release
> > file each time.
The odd thing I have in a specific configuration is that depmod is
missing the kernelrelease when I
On 12.07.13 01:49:40, tip-bot for Robert Richter wrote:
> Commit-ID: 107de3724eff5a6fa6474a4d2aa5460b63749ebf
> Gitweb: http://git.kernel.org/tip/107de3724eff5a6fa6474a4d2aa5460b63749ebf
> Author: Robert Richter
> AuthorDate: Tue, 11 Jun 2013 17:22:38 +0200
> Committer: A
's
> something else being the current bottleneck, besides page init
> granularity.
>
> Can you boot with just a few gigs of RAM and stuff the rest into hotplug
> memory, and then hot-add that memory? That would allow easy profiling of
> remaining overhead.
>
> Sid
Commit-ID: 5125bc22e7871b46e71312d6cc4455e9eea1619d
Gitweb: http://git.kernel.org/tip/5125bc22e7871b46e71312d6cc4455e9eea1619d
Author: Robert Richter
AuthorDate: Fri, 3 May 2013 15:49:53 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 8 Jul 2013 17:31:34 -0300
tools: Get
Commit-ID: a4147f0f91386540316e468f3a3674a498dada5f
Gitweb: http://git.kernel.org/tip/a4147f0f91386540316e468f3a3674a498dada5f
Author: Robert Richter
AuthorDate: Wed, 8 May 2013 11:43:34 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 8 Jul 2013 18:09:52 -0300
perf tools
Commit-ID: 107de3724eff5a6fa6474a4d2aa5460b63749ebf
Gitweb: http://git.kernel.org/tip/107de3724eff5a6fa6474a4d2aa5460b63749ebf
Author: Robert Richter
AuthorDate: Tue, 11 Jun 2013 17:22:38 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 8 Jul 2013 17:34:00 -0300
perf tools
Commit-ID: 761a0f395d5d8b7aafe563ecefbc8cf71a214a91
Gitweb: http://git.kernel.org/tip/761a0f395d5d8b7aafe563ecefbc8cf71a214a91
Author: Robert Richter
AuthorDate: Mon, 6 May 2013 20:40:14 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 8 Jul 2013 17:31:49 -0300
perf tools
Commit-ID: 107de3724eff5a6fa6474a4d2aa5460b63749ebf
Gitweb: http://git.kernel.org/tip/107de3724eff5a6fa6474a4d2aa5460b63749ebf
Author: Robert Richter robert.rich...@linaro.org
AuthorDate: Tue, 11 Jun 2013 17:22:38 +0200
Committer: Arnaldo Carvalho de Melo a...@redhat.com
CommitDate: Mon
Commit-ID: 761a0f395d5d8b7aafe563ecefbc8cf71a214a91
Gitweb: http://git.kernel.org/tip/761a0f395d5d8b7aafe563ecefbc8cf71a214a91
Author: Robert Richter robert.rich...@calxeda.com
AuthorDate: Mon, 6 May 2013 20:40:14 +0200
Committer: Arnaldo Carvalho de Melo a...@redhat.com
CommitDate: Mon
Commit-ID: a4147f0f91386540316e468f3a3674a498dada5f
Gitweb: http://git.kernel.org/tip/a4147f0f91386540316e468f3a3674a498dada5f
Author: Robert Richter robert.rich...@calxeda.com
AuthorDate: Wed, 8 May 2013 11:43:34 +0200
Committer: Arnaldo Carvalho de Melo a...@redhat.com
CommitDate: Mon
Commit-ID: 5125bc22e7871b46e71312d6cc4455e9eea1619d
Gitweb: http://git.kernel.org/tip/5125bc22e7871b46e71312d6cc4455e9eea1619d
Author: Robert Richter robert.rich...@calxeda.com
AuthorDate: Fri, 3 May 2013 15:49:53 +0200
Committer: Arnaldo Carvalho de Melo a...@redhat.com
CommitDate: Mon
granularity.
Can you boot with just a few gigs of RAM and stuff the rest into hotplug
memory, and then hot-add that memory? That would allow easy profiling of
remaining overhead.
Side note:
Robert Richter and Boris Petkov are working on 'persistent events' support
for perf, which
On 12.07.13 01:49:40, tip-bot for Robert Richter wrote:
Commit-ID: 107de3724eff5a6fa6474a4d2aa5460b63749ebf
Gitweb: http://git.kernel.org/tip/107de3724eff5a6fa6474a4d2aa5460b63749ebf
Author: Robert Richter robert.rich...@linaro.org
AuthorDate: Tue, 11 Jun 2013 17:22:38 +0200
On 11.07.13 10:16:18, Linus Torvalds wrote:
On Thu, Jul 11, 2013 at 6:54 AM, Michal Marek mma...@suse.cz wrote:
Yeah. It also reveals another bug that we rewrite the kernel.release
file each time.
The odd thing I have in a specific configuration is that depmod is
missing the kernelrelease
On 21.06.13 14:50:20, Robert Richter wrote:
> On 20.06.13 12:26:03, Arnaldo Carvalho de Melo wrote:
> > Robert, so this one is with:
> >
> > cd tools/perf
> > make install-doc
> >
> > I tested with:
> >
> > make -C tools/perf O=/t
On 21.06.13 14:50:20, Robert Richter wrote:
On 20.06.13 12:26:03, Arnaldo Carvalho de Melo wrote:
Robert, so this one is with:
cd tools/perf
make install-doc
I tested with:
make -C tools/perf O=/tmp/build/perf install-doc
and it works, so it is just the in tree
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 no
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 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_I
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 this could
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, 0
On 26.06.13 13:45:38, Ingo Molnar wrote:
* Robert Richter r...@kernel.org 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
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 p
On 25.06.13 17:29:41, Borislav Petkov wrote:
> How about
>
> perf_add_pevent?
>
> It is nice and short, although maybe too short but "pevent" is almost
> like a special term and the name shows that it is a special type of
> event, i.e. a p-event.
Fine with me, though it's more for internal
On 25.06.13 11:37:06, Borislav Petkov wrote:
> On Tue, Jun 25, 2013 at 11:24:39AM +0200, Robert Richter wrote:
> > I also see 'pers_' not as an optimum since it could be mixed-up easily
> > with 'perf_'. Maybe we take 'persist_' instead?
>
> Yep, al
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
On 25.06.13 09:44:01, Peter Zijlstra wrote:
> Elsewhere in this series you use 'pers' to shorten things; it reads a
> bit odd to me because 'pers' is the Dutch word for press (both meanings
> transfer) but that is just something I'll have to live with isn't it ;-)
>
> As for tracepoint, it seems
On 24.06.13 11:32:04, Peter Zijlstra wrote:
> I generally disapprove of indented labels. None of the perf code has
> that and the tools are easy to 'fix'.
>
> My quiltrc contains:
>
> QUILT_DIFF_OPTS="-F ^[[:alpha:]\$_].*[^:]\$"
>
> my .gitconfig contains:
>
> [diff "default"]
>
On 24.06.13 21:24:04, Borislav Petkov wrote:
> On Mon, Jun 24, 2013 at 11:28:07AM +0200, Peter Zijlstra wrote:
> > I find this patch incomplete for its asymmetric; there a dec, but not an
> > implied inc.
>
> There's one in perf_mmap_open.
>
> Basically the idea was to pull up the ->mmap_count
On 24.06.13 11:44:58, Peter Zijlstra wrote:
> > +static void del_persistent_event(int cpu, struct perf_event_attr *attr)
> > +{
> > + struct pers_event_desc *desc, *tmp;
> > + struct perf_event *event = NULL;
> > +
> > + list_for_each_entry_safe(desc, tmp, _cpu(pers_events, cpu), plist) {
>
On 24.06.13 11:44:58, Peter Zijlstra wrote:
+static void del_persistent_event(int cpu, struct perf_event_attr *attr)
+{
+ struct pers_event_desc *desc, *tmp;
+ struct perf_event *event = NULL;
+
+ list_for_each_entry_safe(desc, tmp, per_cpu(pers_events, cpu), plist) {
+
On 24.06.13 21:24:04, Borislav Petkov wrote:
On Mon, Jun 24, 2013 at 11:28:07AM +0200, Peter Zijlstra wrote:
I find this patch incomplete for its asymmetric; there a dec, but not an
implied inc.
There's one in perf_mmap_open.
Basically the idea was to pull up the -mmap_count decrement
On 24.06.13 11:32:04, Peter Zijlstra wrote:
I generally disapprove of indented labels. None of the perf code has
that and the tools are easy to 'fix'.
My quiltrc contains:
QUILT_DIFF_OPTS=-F ^[[:alpha:]\$_].*[^:]\$
my .gitconfig contains:
[diff default]
xfuncname =
On 25.06.13 09:44:01, Peter Zijlstra wrote:
Elsewhere in this series you use 'pers' to shorten things; it reads a
bit odd to me because 'pers' is the Dutch word for press (both meanings
transfer) but that is just something I'll have to live with isn't it ;-)
As for tracepoint, it seems
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 the
On 25.06.13 11:37:06, Borislav Petkov wrote:
On Tue, Jun 25, 2013 at 11:24:39AM +0200, Robert Richter wrote:
I also see 'pers_' not as an optimum since it could be mixed-up easily
with 'perf_'. Maybe we take 'persist_' instead?
Yep, although it reads wrong:
perf_add_persist_event
We
On 25.06.13 17:29:41, Borislav Petkov wrote:
How about
perf_add_pevent?
It is nice and short, although maybe too short but pevent is almost
like a special term and the name shows that it is a special type of
event, i.e. a p-event.
Fine with me, though it's more for internal usage. There
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 'attrnum' 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 21:45:11, Ingo Molnar wrote:
* Peter Zijlstra pet...@infradead.org 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
On 21.06.13 10:34:37, Arnaldo Carvalho de Melo wrote:
> Em Fri, Jun 21, 2013 at 02:50:20PM +0200, Robert Richter escreveu:
> > Jiri and Arnaldo,
> >
> > On 20.06.13 12:26:03, Arnaldo Carvalho de Melo wrote:
> > > Robert, so this one is with:
> > >
> &g
t the in tree build that fails.
The patch below fixes this. Thanks for reporting.
-Robert
>From 69714303856005a1dc84c0594a4c3ec1013f8a80 Mon Sep 17 00:00:00 2001
From: Robert Richter
Date: Fri, 21 Jun 2013 14:26:44 +0200
Subject: [PATCH] perf tools: Fixing in-tree documentation build error
Fix
below fixes this. Thanks for reporting.
-Robert
From 69714303856005a1dc84c0594a4c3ec1013f8a80 Mon Sep 17 00:00:00 2001
From: Robert Richter robert.rich...@calxeda.com
Date: Fri, 21 Jun 2013 14:26:44 +0200
Subject: [PATCH] perf tools: Fixing in-tree documentation build error
Fixing build error
On 21.06.13 10:34:37, Arnaldo Carvalho de Melo wrote:
Em Fri, Jun 21, 2013 at 02:50:20PM +0200, Robert Richter escreveu:
Jiri and Arnaldo,
On 20.06.13 12:26:03, Arnaldo Carvalho de Melo wrote:
Robert, so this one is with:
cd tools/perf
make install-doc
I tested
On 14.06.13 11:36:00, Namhyung Kim wrote:
> > +static int pers_event_sysfs_register(struct pers_event *event)
> > +{
> > + struct device_attribute *attr = >sysfs.attr;
> > + int idx;
> > +
> > + *attr = (struct device_attribute)__ATTR(, 0444, pers_event_sysfs_show,
> > +
On 14.06.13 11:08:40, Namhyung Kim wrote:
> > - if (perf_evlist__mmap(evlist, opts->mmap_pages, false) < 0) {
> > +try_again2:
> > + if (perf_evlist__mmap(evlist, opts->mmap_pages, opts->mmap_ro) < 0) {
> > + if (!opts->mmap_ro && errno == EACCES) {
> > +
On 14.06.13 11:15:13, Namhyung Kim wrote:
> > +int perf_get_persistent_event_fd(unsigned cpu, struct perf_event_attr
> > *attr)
> > +{
> > + struct pers_event_desc *desc;
> > +
> > + if (cpu >= (unsigned)nr_cpu_ids)
> > + return -EINVAL;
> > +
> > + list_for_each_entry(desc,
On 14.06.13 11:15:13, Namhyung Kim wrote:
+int perf_get_persistent_event_fd(unsigned cpu, struct perf_event_attr
*attr)
+{
+ struct pers_event_desc *desc;
+
+ if (cpu = (unsigned)nr_cpu_ids)
+ return -EINVAL;
+
+ list_for_each_entry(desc, per_cpu(pers_events,
On 14.06.13 11:08:40, Namhyung Kim wrote:
- if (perf_evlist__mmap(evlist, opts-mmap_pages, false) 0) {
+try_again2:
+ if (perf_evlist__mmap(evlist, opts-mmap_pages, opts-mmap_ro) 0) {
+ if (!opts-mmap_ro errno == EACCES) {
+ opts-mmap_ro = true;
+
On 14.06.13 11:36:00, Namhyung Kim wrote:
+static int pers_event_sysfs_register(struct pers_event *event)
+{
+ struct device_attribute *attr = event-sysfs.attr;
+ int idx;
+
+ *attr = (struct device_attribute)__ATTR(, 0444, pers_event_sysfs_show,
+
Michal,
please apply this fix, ideally for v3.10 if possible.
Thanks,
-Robert
On 02.05.13 08:50:37, Robert Richter wrote:
> From: Robert Richter
>
> Make modules_install fails with -j option:
>
>DEPMOD
> Usage: .../.source/linux/scripts/depmod.sh /sbin
Michal,
please apply this fix, ideally for v3.10 if possible.
Thanks,
-Robert
On 02.05.13 08:50:37, Robert Richter wrote:
From: Robert Richter robert.rich...@calxeda.com
Make modules_install fails with -j option:
DEPMOD
Usage: .../.source/linux/scripts/depmod.sh /sbin/depmod
tent event
Robert Richter (10):
perf, persistent: Rework struct pers_event_desc
perf, persistent: Remove rb_put()
perf, persistent: Introduce get_persistent_event()
perf, persistent: Reworking perf_get_persistent_event_fd()
perf, persistent: Protect event lists with mutex
perf, persist
From: Borislav Petkov
Rename ring_buffer-handling functions consistently with the "rb_"
prefix.
Signed-off-by: Borislav Petkov
Signed-off-by: Robert Richter
---
kernel/events/core.c| 37 +
kernel/events/ring_buffer.c | 7 +++
2 fil
and not at mmap
time so that we can log samples into them regardless of whether there
are readers in userspace or not.
Changes made by Robert Richter :
* Fixing wrongly determined attribute size.
* The default buffer size used to setup event buffers with perf tools
is 512k. Using the same buffer size
From: Robert Richter
rb_put() is called already in perf_event_release_kernel(), so no need
to do the same in del_persistent_event(). We also don't need it in
add_persistent_event_on_cpu() after a rework. Since there are no users
of rb_put() anymore, we can make it private again to only
events
From: Borislav Petkov
Add the needed pieces for persistent events which makes them
process-agnostic. Also, make their buffers read-only when mmaping them
from userspace.
While at it, do not return a void function, as caught by Fengguang's
build robot.
Changes made by Robert Richter :
* mmap
From: Robert Richter
Struct pers_event_desc is only used in kernel/events/persistent.c.
Moving it there. Also, removing attr member as this is a copy of
event->attr.
Signed-off-by: Robert Richter
Signed-off-by: Robert Richter
---
include/linux/perf_event.h | 7 ---
kernel/eve
From: Borislav Petkov
... for MCEs collection.
Changes made by Robert Richter :
The mce_record tracepoint needs tracepoints to be enabled. Fixing
build error for no-tracepoints configs.
Signed-off-by: Borislav Petkov
[ Fix build error for no-tracepoints configs ]
Signed-off-by: Robert
From: Robert Richter
Protect esp. access to struct pers_event_desc *desc. There are race
conditions possible where the descriptor could be removed from list
while it is used.
Signed-off-by: Robert Richter
Signed-off-by: Robert Richter
---
kernel/events/persistent.c | 33
From: Robert Richter
There is already a function anon_inode_getfd() that does already all
the work. Reworking and simplifying code.
Signed-off-by: Robert Richter
Signed-off-by: Robert Richter
---
kernel/events/persistent.c | 35 +++
1 file changed, 7
From: Robert Richter
Check if an event already exists before adding it.
Signed-off-by: Robert Richter
Signed-off-by: Robert Richter
---
kernel/events/persistent.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/events/persistent.c b/kernel/events/persistent.c
index 586cea5
From: Robert Richter
Usually a fd close leads to the release of the event too. For
persistent events this is different as the events should be
permanently enabled in the system. Using reference counting to avoid
releasing an event during a fd close. This also allows it to have
multiple users
From: Robert Richter
For later adding persistent events to sysfs we need a name for each
event. Adding a name to each persistent event.
Signed-off-by: Robert Richter
Signed-off-by: Robert Richter
---
arch/x86/kernel/cpu/mcheck/mce.c | 3 ++-
include/linux/perf_event.h | 4
From: Robert Richter
Reducing duplicate code by introducing function get_persistent_event()
to get the descriptor of an persistent event.
Signed-off-by: Robert Richter
Signed-off-by: Robert Richter
---
kernel/events/persistent.c | 36 ++--
1 file changed, 22
From: Robert Richter
We want to use the kernel's pmu design to later expose persistent
events via sysfs to userland. Initially implement a persistent pmu.
The format syntax is introduced allowing to set bits anywhere in
struct perf_event_attr. This is used in this case to set the
persistent
From: Robert Richter
Expose persistent events in the system to userland using sysfs. Perf
tools are able to read existing pmu events from sysfs. Now we use a
persistent pmu as an event container containing all registered
persistent events of the system. This patch adds dynamically
registration
From: Robert Richter
Header files of libtraceevent or no longer local headers. Thus, use
default path notation for them. Also removing extra traceevent include
path and instead handle this similar to liblk.
Signed-off-by: Robert Richter
Signed-off-by: Robert Richter
---
tools/perf/Makefile
From: Robert Richter
Fixing build errors with O and DESTDIR make vars set:
$ make prefix=/usr/local O=$builddir DESTDIR=$destdir -C tools/ perf
...
make[1]: Entering directory `.../.source/perf/tools/perf'
CC .../.build/perf/perf/util/parse-events.o
util/parse-events.c:14:32: fatal
From: Robert Richter robert.rich...@linaro.org
Fixing build errors with O and DESTDIR make vars set:
$ make prefix=/usr/local O=$builddir DESTDIR=$destdir -C tools/ perf
...
make[1]: Entering directory `.../.source/perf/tools/perf'
CC .../.build/perf/perf/util/parse-events.o
util/parse
From: Robert Richter robert.rich...@linaro.org
Header files of libtraceevent or no longer local headers. Thus, use
default path notation for them. Also removing extra traceevent include
path and instead handle this similar to liblk.
Signed-off-by: Robert Richter robert.rich...@linaro.org
Signed
From: Robert Richter robert.rich...@linaro.org
We want to use the kernel's pmu design to later expose persistent
events via sysfs to userland. Initially implement a persistent pmu.
The format syntax is introduced allowing to set bits anywhere in
struct perf_event_attr. This is used in this case
From: Robert Richter robert.rich...@linaro.org
Expose persistent events in the system to userland using sysfs. Perf
tools are able to read existing pmu events from sysfs. Now we use a
persistent pmu as an event container containing all registered
persistent events of the system. This patch adds
From: Robert Richter robert.rich...@linaro.org
For later adding persistent events to sysfs we need a name for each
event. Adding a name to each persistent event.
Signed-off-by: Robert Richter robert.rich...@linaro.org
Signed-off-by: Robert Richter r...@kernel.org
---
arch/x86/kernel/cpu/mcheck
From: Robert Richter robert.rich...@linaro.org
Reducing duplicate code by introducing function get_persistent_event()
to get the descriptor of an persistent event.
Signed-off-by: Robert Richter robert.rich...@linaro.org
Signed-off-by: Robert Richter r...@kernel.org
---
kernel/events
From: Robert Richter robert.rich...@linaro.org
Usually a fd close leads to the release of the event too. For
persistent events this is different as the events should be
permanently enabled in the system. Using reference counting to avoid
releasing an event during a fd close. This also allows
From: Robert Richter robert.rich...@linaro.org
Check if an event already exists before adding it.
Signed-off-by: Robert Richter robert.rich...@linaro.org
Signed-off-by: Robert Richter r...@kernel.org
---
kernel/events/persistent.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel
1201 - 1300 of 1735 matches
Mail list logo
