type of additional data?
> > .TP
> > .BR PERF_SAMPLE_BRANCH_STACK " (Since Linux 3.4)"
> > [To be documented]
>
> requested branch stack - only supported on intel machines which has LBR
> feature(?). See branch_sample_type.
I'll add.
> > .RE
>
/sys/bus/event_source/devices/
subsections near the end to document the files pertaining to perf_event.
Thanks
Vince Weaver
vincent.wea...@maine.edu
.\" Hey Emacs! This file is -*- nroff -*- source.
.\"
.\" Copyright (c) 2012, Vincent Weaver
.\"
.\" This is free documentat
st default to 0
with no initialization currently.
Vince Weaver
vincent.wea...@maine.edu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
he PMU internally is just like that of an original Pentium, but
a "P6-like" MSR interface is provided. The interface is different enough
from a real P6 that it's not easy (or practical) to re-use the code in
perf_event_p6.c
Signed-off-by: Vince Weaver
diff -Nur linux-3.6-rc6
al) to re-use the code in
perf_event_p6.c
Acked-by: Lawrence F Meadows
Acked-by: Cyrill Gorcunov
Signed-off-by: Vince Weaver
diff -Nur linux-3.6-rc6/arch/x86/include/asm/msr-index.h
linux-3.6-rc6-mic/arch/x86/include/asm/msr-index.h
--- linux-3.6-rc6/arch/x86/include/asm/msr-index.h 2012-
On Wed, 28 Aug 2013, Dave Jones wrote:
> Quite often just rerunning that last syscall that caused the oops/warn
> isn't sufficient to trigger an issue. (Though it may be for this specific
> bug that may not be the case..)
>
> Vince has a variant of trinity focussed just on perf which also has some
I guess I should have been noisier about this at the time.
Linux 3.9 came with commit
e259514eef764a5286873618e34c560ecb6cff13
that enabled AMD fam15h Northbridge support, by exposing the events as
part of the core CPU.
Then Linux 3.10 changed this with
c43ca5091a374c1f6778bd7e4a39a5a1073
On Mon, 8 Jul 2013, Jiri Olsa wrote:
> On Wed, Jul 03, 2013 at 09:49:29AM +0200, Peter Zijlstra wrote:
> > On Tue, Jul 02, 2013 at 11:15:59PM -0400, Vince Weaver wrote:
> need to check if that does not break anything else ;-)
I've applied your patch to stock 3.10 and am now
On Mon, 8 Jul 2013, Peter Zijlstra wrote:
> Urgh, so the 3.9 patches should never have been merged and sunk in while I was
> doing my vegetable imitation.
>
> Stephane agreed with the change in 3.10; and I suppose he overlooked the fact
> that people were already using it :/ I specifically asked
In include/uapi/linux/perf_event.h we describe the
PERF_SAMPLE_BRANCH_STACK fields in the PERF_RECORD_SAMPLE
to be of type struct perf_branch_entry, but that structure
is not exported to the user.
Should we not export that structure, something like the following?
Signed-off-by: Vince Weaver
ously just detect what processor you're on with
> cpuid or whatever, but it's a bit of a hack. And that really doesn't
> work for non-cpu PMUs.
why is it a hack to use cpuid?
People have done event lists in userspace for years. Why must it be the
kernel's job?
Vince Weav
On Tue, 9 Jul 2013, Peter Zijlstra wrote:
> On Mon, Jul 08, 2013 at 10:24:34PM -0400, Vince Weaver wrote:
> >
> > So something like they have on ARM?
> >
> > vince@pandaboard:/sys/bus/event_source/devices$ ls -l
> > lrwxrwxrwx 1 root root 0 Jul 8 21:57 ARMv7 C
On Tue, 9 Jul 2013, Michael Ellerman wrote:
> On Mon, Jul 08, 2013 at 10:24:34PM -0400, Vince Weaver wrote:
> > why is it a hack to use cpuid?
>
> Because you're assuming that the PMU the kernel has exposed is for the
> cpu you happen to be executing on.
>
> But the
On Wed, 10 Jul 2013, Dave Jones wrote:
> Something is really fucked up in the kernel side of perf.
> I get this right after booting..
>
> [ 114.516619] perf samples too long (4262 > 2500), lowering
> kernel.perf_event_max_sample_rate to 5
>
> That's before I even get a chance to log in, so
On Wed, 10 Jul 2013, Ingo Molnar wrote:
> Exactly - PMUs enumerated in /sys should be self-identifying, it's a
> hardware topology after all ...
>
> Anytime userspace is forced to look into /proc, or into weird places in
> /sys it's a FAIL really.
well on x86 you have to look at /proc/cpuinfo
On Thu, 11 Jul 2013, Will Deacon wrote:
> On Tue, Jul 09, 2013 at 04:05:30PM +0100, Vince Weaver wrote:
> > libpfm4 uses the
> >CPU part : 0xc09
> > line in /proc/cpuinfo on ARM, and that's enough for the processors PAPI
>
> The CPU part you cite is actua
On Fri, 12 Jul 2013, Dave Jones wrote:
>
> Here's a fun trick:
>
> trinity -c perf_event_open -C4 -q -l off
>
> Within about a minute, that brings any of my boxes to its knees.
> The softlockup detector starts going nuts, and then the box wedges solid.
are you running with the patch
[PATCH 1
On Tue, 23 Jul 2013, tip-bot for Peter Zijlstra wrote:
> Commit-ID: a5cdd40c9877e9aba704c020fd65d26b5cfecf18
> Gitweb: http://git.kernel.org/tip/a5cdd40c9877e9aba704c020fd65d26b5cfecf18
> Author: Peter Zijlstra
> AuthorDate: Tue, 16 Jul 2013 17:09:07 +0200
> Committer: Ingo Molnar
> Co
Without the following patch I have problems compiling code using
the new PERF_EVENT_IOC_ID ioctl(). It looks like u64 was used
instead of __u64
Signed-off-by: Vince Weaver
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index ca1d90b..40a1fb8 100644
--- a
This patch somehow breaks the perf-ABI.
If I take a program that reads "mmap->cap_usr_rdpmc" and compile it
against the new header with this change (say from 3.12-rc1)
and then run it on an old kernel (say 3.11) then I get "0" for
cap_usr_rdpmc.
If I take the same program and recompile against t
On Tue, 17 Sep 2013, Vince Weaver wrote:
>
> This patch somehow breaks the perf-ABI.
>
> If I take a program that reads "mmap->cap_usr_rdpmc" and compile it
> against the new header with this change (say from 3.12-rc1)
> and then run it on an old kerne
On Wed, 11 Sep 2013, Vince Weaver wrote:
>
> I got this hard lockup running my perf_fuzzer on 3.11 on a core2.
> I guess I should try to reproduce it on linus-git but was hoping
> I could wait until -rc1 before trying that.
OK, I can also lock up 3.12-rc1 using the perf_fuzzer.
On Wed, 18 Sep 2013, Adrian Hunter wrote:
> On 17/09/13 23:23, Vince Weaver wrote:
> >
> > This patch somehow breaks the perf-ABI.
> >
> > If I take a program that reads "mmap->cap_usr_rdpmc" and compile it
> > against the new header with this cha
On Wed, 18 Sep 2013, Peter Zijlstra wrote:
> > This patch somehow breaks the perf-ABI.
>
> Difficult call that..
OK, let me rephrase.
This change broke existing working code.
Can you point to any code that is fixed by the commit?
If not, I think the rule is you revert the changeset.
Or you c
On Wed, 18 Sep 2013, Peter Zijlstra wrote:
> On Wed, Sep 18, 2013 at 10:19:32AM -0400, Vince Weaver wrote:
> > Can you point to any code that is fixed by the commit?
>
> I have some, but I don't think a lot of people use it.
>
> Would you be ok with something like the
On Thu, 19 Sep 2013, Andi Kleen wrote:
> Vince Weaver writes:
>
> > On Wed, 11 Sep 2013, Vince Weaver wrote:
> >
> >>
> >> I got this hard lockup running my perf_fuzzer on 3.11 on a core2.
> >> I guess I should try to reproduce it on linus-git but w
On Thu, 19 Sep 2013, Ingo Molnar wrote:
> To solve all that make this change explicit, detectable and self-contained,
> by iterating the ABI the following way:
>
> - Always clear bit 0, and rename it to usrpage->cap_bit0, to at least not
>confuse old user-space binaries. RDPMC will be marked
On Wed, 4 Sep 2013, Andi Kleen wrote:
> > What does this mean? The above values are exported as part of
> > include/uapi/linux/perf_event.h
> > Do they not work yet?
>
> You can filter on the fields, but you can't see them outside
> the kernel driver yet. The patch to see them is still pendi
I got this hard lockup running my perf_fuzzer on 3.11 on a core2.
I guess I should try to reproduce it on linus-git but was hoping
I could wait until -rc1 before trying that.
I'm not really sure where to report lockups like this because it's sort
of unclear what exactly the problem is. perf? ftr
On Thu, 12 Sep 2013, Ingo Molnar wrote:
> * Andi Kleen wrote:
>
> > On Tue, Jul 23, 2013 at 05:27:43PM -0400, Vince Weaver wrote:
> > >
> > > I hate having to justify why breaking the ABI is unacceptable.
> >
> > Well it's a testing ABI, so we c
On Fri, 13 Sep 2013, Peter Zijlstra wrote:
> On Fri, Sep 13, 2013 at 11:50:57AM +0200, Ingo Molnar wrote:
> > For example if we added 'type' as well we could expose the generic,
> > hardware-independent events via sysfs as well.
>
> Type is already fully implied by where you'll find the event in
On Tue, 8 Oct 2013, Ingo Molnar wrote:
> The base cost of perf is +151k - not small but a far cry from your claimed
> +700k ...
Things might get that bad if we enable full event lists in the kernel for
all of x86, as Power is starting to do.
The patch to add all Power7 events cfe0d8ba14a1d9824
Hello,
I've finally found time to track down why perf_event/rdpmc self-monitoring
overhead was so bad.
To summarize, a test which does:
perf_event_open()
ioctl(PERF_EVENT_IOC_ENABLE)
read() /* either via syscall or the rdpmc code listed in
include/uapi/linux/perf_event.h
.
With perf_event you have one mmap page per event so touching all the pages
starts racking up some overhead if you have multiple events, but yes
probably lost in the noise if you do it at open() rather than at read().
It's also hard to have a dummy read of a page w/o the compiler
o
On Mon, 2 Sep 2013, Stephane Eranian wrote:
> On Mon, Sep 2, 2013 at 4:50 AM, Andi Kleen wrote:
> > Stephane Eranian writes:
> >
> >> I don't see a flag in mmap() to fault it in immediately.
> >
> > MAP_PRESENT
> >
> I could not find this constant defined anywhere in the kernel source tree
> nor
On Tue, 3 Sep 2013, Ingo Molnar wrote:
>* New ABI details:
> . Make Power7 events available via sysfs, by Runzhen Wang.
So we're really going to add 100+ Power7 events to the stable sysfs ABI?
Are all the new events listed under the sysfs ABI documentation?
Are we going to add all of
On Sat, 20 Apr 2013, Andi Kleen wrote:
> From: Andi Kleen
>
> Haswell has two additional LBR from flags for TSX: intx and abort, implemented
> as a new v4 version of the LBR format.
>
> Handle those in and adjust the sign extension code to still correctly extend.
> The flags are exported simila
On Tue, 3 Sep 2013, Andi Kleen wrote:
> > > + PERF_SAMPLE_BRANCH_ABORT_TX = 1U << 7, /* transaction aborts */
> > > + PERF_SAMPLE_BRANCH_IN_TX= 1U << 8, /* in transaction */
> > > + PERF_SAMPLE_BRANCH_NO_TX= 1U << 9, /* not in transaction */
> >
> > so if you specify these fla
On Thu, 26 Sep 2013, Jiri Olsa wrote:
> On Wed, Sep 25, 2013 at 03:46:58PM -0400, Vince Weaver wrote:
> > On Wed, 25 Sep 2013, Jiri Olsa wrote:
> >
> > > --- a/include/uapi/linux/perf_event.h
> > > +++ b/include/uapi/linux/perf_event.h
> > >
On Wed, 25 Sep 2013, Jiri Olsa wrote:
> --- a/include/uapi/linux/perf_event.h
> +++ b/include/uapi/linux/perf_event.h
> @@ -325,6 +325,7 @@ struct perf_event_attr {
> #define PERF_EVENT_IOC_SET_OUTPUT_IO ('$', 5)
> #define PERF_EVENT_IOC_SET_FILTER_IOW('$', 6, char *)
> #define PERF_EVE
Hello
quick summary: the p6 code looks to be buggy and is only currently
working by luck. I'm trying to work out how to best fix the KNC
code which is based on the p6 PMU driver.
While working on the KNC PMU we ran into the following problem.
Between 2.6.33 and 2.6.34 the kernel was chang
they are inline and probably performance critical
I took the easy way out and just duplicated the code.
Thanks,
Vince Weaver
vincent.wea...@maine.edu
--
char x,_,*O="l1f41mm65mm5OU5m5_55mmmGUml1ED1ooG_ol\\lDClN:eml9niiobTQO"
"m8dlYoo=HUmmaNEnCDY[l1G@7oo975l1>UImmS
systems,
so remove this workaround so we get proper overflow support.
Signed-off-by: Vince Weaver
diff -ur linux-3.7-rc1.orig/arch/x86/kernel/cpu/perf_event_knc.c
linux-3.7-rc1/arch/x86/kernel/cpu/perf_event_knc.c
--- linux-3.7-rc1.orig/arch/x86/kernel/cpu/perf_event_knc.c 2012-10-14
17:41
The origin of this problem is the KNC driver being based on the P6 one.
The P6 driver also has this issue, but works anyway due to various
lucky accidents.
Signed-off-by: Vince Weaver
diff -ur linux-3.7-rc1.orig/arch/x86/kernel/cpu/perf_event_knc.c
linux-3.7-rc1/arch/x86/kernel/cpu/perf_event_kn
tel.c
with some minor changes, as it looks like it would not be
worth the trouble to change that code to be MSR-configurable.
Signed-off-by: Vince Weaver
diff -ur linux-3.7-rc1.orig/arch/x86/kernel/cpu/perf_event_knc.c
linux-3.7-rc1/arch/x86/kernel/cpu/perf_event_knc.c
--- linux-3.7-rc1.orig/arc
On Wed, 17 Oct 2012, Ingo Molnar wrote:
> How well tested is this on real hardware and how robust is the
> hardware with this? Since it's a new PMU driver for v3.7, and if
> these are reasonably well tested, then we could send these to
> Linus via perf/urgent, so that they don't miss and have t
but there's also a lot of low-level
changes too, some of it due to the fact that KNC is 64-bit x86 but has no
support for SSE (so you need to handle that properly or none of your
userspace will run).
Thanks,
Vince Weaver
vincent.wea...@maine.edu
--
To unsubscribe from this list: send the line
() and p6_pmu_disable_event()
Changes around the 2.6.33 to 2.6.34 transition left some
confusing dead code around that was no longer necessary.
I've tested all of these on a Pentium II machine I brought out of
retirement.
Vince Weaver
vincent.wea...@maine.edu
--
char x
According to Intel SDM Volume 3B, FP_ASSIST is limited to Counter 1 only,
not Counter 0.
Tested on a Pentium II.
Signed-off-by: Vince Weaver
diff -ur linux-3.7-rc1.orig/arch/x86/kernel/cpu/perf_event_p6.c
linux-3.7-rc1/arch/x86/kernel/cpu/perf_event_p6.c
--- linux-3.7-rc1.orig/arch/x86
This patch updates the generic events on p6, including some new
extended cache events.
Values for these events were taken from the equivelant PAPI predefined
events.
Tested on a Pentium II.
Signed-off-by: Vince Weaver
diff -ur linux-3.7-rc1.orig/arch/x86/kernel/cpu/perf_event_p6.c
linux
on.
Signed-off-by: Vince Weaver
diff -ur linux-3.7-rc1.orig/arch/x86/kernel/cpu/perf_event_p6.c
linux-3.7-rc1/arch/x86/kernel/cpu/perf_event_p6.c
--- linux-3.7-rc1.orig/arch/x86/kernel/cpu/perf_event_p6.c 2012-10-14
17:41:04.0 -0400
+++ linux-3.7-rc1/arch/x86/kernel/cpu/perf_even
While trying to write a perf_event/mmap test for my perf_event
test-suite I came across a missing field description in the
PERF_RECORD_SAMPLE documentation.
Signed-off-by: Vince Weaver
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index 4f63c05..9fa9c62
? This is likely to become the document
that most users of the perf_event ABI will be using so it's important
to catch any problems with it now.
Thanks,
Vince Weaver
vincent.wea...@maine.edu
--
.\" Hey Emacs! This file is -*- nroff -*- source.
.\"
.\" Copyright (c) 2012, Vince
r the longest
syscall manpage. That's a bit scary.
Vince Weaver
vincent.wea...@maine.edu
--
.\" Hey Emacs! This file is -*- nroff -*- source.
.\"
.\" Copyright (c) 2012, Vincent Weaver
.\"
.\" This is free documentation; you can redistribute it and/or
.\" modif
On Thu, 20 Dec 2012, Jiri Olsa wrote:
> BR_MISP_EXEC.ALL_BRANCHES,event=0x89,umask=0xff
> BR_MISP_EXEC.COND,event=0x89,umask=0x1
> BR_MISP_EXEC.DIRECT_NEAR_CALL,event=0x89,umask=0x10
> BR_MISP_EXEC.INDIRECT_JMP_NON_CALL_RET,event=0x89,umask=0x4
> BR_MISP_EXEC.INDIRECT_NEAR_CALL,event=0x89,umask=0x
On Fri, 21 Dec 2012, Andi Kleen wrote:
> > I hate to sound like a broken record here, but, again, what's the
> > rationalization for not using libpfm4 here?
>
> Personally I always hated the libpfm4 syntax. It's even worse than
> oprofile.
how so? The libpfm4 event names are more or less the s
On Thu, 18 Apr 2013, Peter Zijlstra wrote:
> On Mon, 2013-04-15 at 03:42 -0700, tip-bot for Tommi Rantala wrote:
> > Commit-ID: 8176cced706b5e5d15887584150764894e94e02f
> > Gitweb:
> > http://git.kernel.org/tip/8176cced706b5e5d15887584150764894e94e02f
> > Author: Tommi Rantala
> > Autho
Current git of my perf_fuzzer tool (recently enhanced to fork and prctl)
https://github.com/deater/perf_event_tests/tree/master/fuzzer
rapidly crashes my machine with a
Warning followed by NMI errors then an rcu_stall then stuck cpus.
This is on a core2 machine.
I don't think these traces look
this:
/* log_to_code output from ./newcrash-bisect31 */
/* by Vince Weaver
#include
#include
#include
#include
#include
#include
#include
#include
#include
int fd[1024];
struct perf_event_attr pe[1024];
char *mmap_result[1024];
int forked_pid;
int perf_event_open(struct perf_event_attr *hw_event
On Mon, 3 Jun 2013, Peter Zijlstra wrote:
> Seems to cure it... I'm going to let it run over night.
[sorry for the delay in testing, was at the hospital waiting for
a new baby, and the free wi-fi had the ssh port blocked]
I'm running 3.10-rc4 with your patch plus the 3-line fixup applied and my
On Wed, 29 May 2013, Peter Zijlstra wrote:
> Hurm.. I don't suppose you have an easy reproducer handy eh? I'll go
> stare at it. At least the current state is better than before, but
> clearly we're not quite there yet.
I've been working on a reproducible test case. Simple modifications to
the
wo or three times.
It leaks 129 pages in user->locked_vm each time you run it.
It took me a while to bisect this down from 10,000 syscalls to just 3.
I now have a tool that can generate valid perf test_cases from my fuzzer
traces, which should be useful.
Vince
/* log_to_code output from bise
On Thu, 30 May 2013, Peter Zijlstra wrote:
>
> Awesome! How specific is it to perf? I mean, would that tool work
> equally well for other tinity report?
No, it's fairly specific to my perf_fuzzer. I only use trinity code to
set up the perf_event_open() attr parameters, everything else I use my
On Tue, 25 Jun 2013, Runzhen Wang wrote:
> This patch makes all the POWER7 events available in sysfs.
>
> ...
>
> $ size arch/powerpc/perf/power7-pmu.o
>text data bss dec hex filename
>3073 2720 0579316a1 arch/powerpc/perf/power7-pmu.o
>
> and
On Mon, 1 Jul 2013, Peter Zijlstra wrote:
> OK, so on my westmere it triggers that WARN in task_ctx_sched_out() a
> _lot_ (I removed the ONCE for easier debugging earlier -- still kinda
> stumped there).
>
> Then this thing causes an RCU stall and starts triggering NMI watchdog
> msgs.. so YAY!
On Mon, 1 Jul 2013, Vince Weaver wrote:
> I'm in the process of kernel bisecting this, though all I can tell you so
> far is 2.6.32 is unaffected by the bug but 3.2 and later are.
well, I spent 2 days bisecting between 3.1 and 3.2 (after
wasting time bisecting between 3.0 and 3.1
OK, I have bisected this problem to the following change:
commit 8dc85d547285668e509f86c177bcd4ea055bcaaf
Author: Peter Zijlstra
Date: Thu Sep 2 16:50:03 2010 +0200
perf: Multiple task contexts
Provide the infrastructure for multiple task contexts.
--
To unsubscribe from this li
Add some documentation for the perf_event related
/sys/bus/event_source/bus/devices/
files, since in theory it's a stable interface and the only
current documentation is some lex and yacc files in the
perf tools directory.
Signed-off-by: Vince Weaver
diff --git a/Documentation/ABI/s
On Wed, 3 Jul 2013, Vince Weaver wrote:
>
> Add some documentation for the perf_event related
> /sys/bus/event_source/bus/devices/
> files, since in theory it's a stable interface and the only
> current documentation is some lex and yacc files in the
> perf tools direc
On Fri, 5 Jul 2013, Jiri Olsa wrote:
> On Thu, Jul 04, 2013 at 11:02:53AM +0200, Peter Zijlstra wrote:
> > On Wed, Jul 03, 2013 at 11:14:40PM -0400, Vince Weaver wrote:
> > >Documentation/ABI/testing/sysfs-bus-event_source-devices-events
> > >
> > > Shoul
On Fri, 14 Jun 2013, Vince Weaver wrote:
> OK, I haven't managed to get a small reproducible test case for the system
> crash yet
I wasted the last 2 days bisecting a 1 syscall trace, but below is a
20-syscall testcase that rapidly makes a core2 machine running 3.10-rc7
unu
On Fri, 28 Jun 2013, Vince Weaver wrote:
> On Fri, 14 Jun 2013, Vince Weaver wrote:
>
> > OK, I haven't managed to get a small reproducible test case for the system
> > crash yet
>
> I wasted the last 2 days bisecting a 1 syscall trace, but below is a
>
value to pass in.
Signed-off-by: Vince Weaver
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
index 3c1cc24..43aae08 100644
--- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
+++ b
Add documentation for various files perf_event creates under
/sys/bus/event_source/devices//
Signed-off-by: Vince Weaver
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices
b/Documentation/ABI/testing/sysfs-bus-event_source-devices
new file mode 100644
index 000..ffa2e4b
On Mon, 15 Jul 2013, Linus Torvalds wrote:
> On Mon, Jul 15, 2013 at 7:38 PM, Dave Jones wrote:
>
> > Interestingly, the 'soft lockups' I was
> > seeing all the time on that box seem to have gone into hiding.
>
> Honestly, I'm somewhat inclined to blame the whole perf situation, and
> saying th
On Fri, 26 Jul 2013, Peter Zijlstra wrote:
> On Thu, Jul 25, 2013 at 11:20:24PM -0400, Vince Weaver wrote:
> >
> > a thing that personally bothers me are these imaginary struct definitions
> > added as part of the documentation that aren't actually available in th
Hello
so my perf_fuzzer has been causing problems again.
After running a while all login shells on the system (even unrelated
local ones) get killed. Nothing is logged when this happens and it
doesn't appear to be OOM related.
In an attempt to find out what was going on I ran the fuzzer with
On Wed, 31 Jul 2013, Dave Jones wrote:
> On Wed, Jul 31, 2013 at 07:47:30PM -0700, Olof Johansson wrote:
> > How long would a useful run of trinity take?
>
> It blew up in a minute or so of runtime when I tried last week.
I also have a chromebook running 3.4 and it is trivially easy to crash it
e
# perf -e "uncore_qpi_0/event=0x102,umask=0x08/"
I confirmed that this last version gives results that agree with the
amount of data that I expected the STREAM benchmark to move across the QPI
link in the second (cross-chip) test of the original script.
Reported-
On Tue, 20 Aug 2013, Catalin Marinas wrote:
> On 20 August 2013 11:03, P J P wrote:
> > -> https://lkml.org/lkml/2013/8/7/259
> >
> > I wanted to confirm if this above fix should also go into ARM64 build Or is
> > ARM64 platform not vulnerable?
>
> It is and I'll push patches to mainline (Will
On Thu, 22 Aug 2013, Robert Richter wrote:
> 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
On Thu, 22 Aug 2013, Robert Richter wrote:
> From: Robert Richter
>
> Implementing ioctl functions to control persistent events. There are
> functions to detach or attach an event to or from a process. The
> PERF_EVENT_IOC_DETACH ioctl call makes an event persistent. After
> closing the event's
On Fri, 23 Aug 2013, Robert Richter wrote:
> I thought it would be clear enough to refer to struct perf_event_attr.
> Since the index usually starts with 0 as in the config fields, I
> assumed this was clear in this case too. Though this can be documented
> better.
Make no assumptions when docume
On Fri, 23 Aug 2013, Borislav Petkov wrote:
> On Fri, Aug 23, 2013 at 12:44:41PM +0200, Robert Richter wrote:
> > On 23.08.13 11:45:56, Robert Richter wrote:
> > > On 23.08.13 11:11:28, Borislav Petkov wrote:
> > > > On Thu, Aug 22, 2013 at 02:18:
On Mon, 8 Jul 2013, Vince Weaver wrote:
If PERF_SAMPLE_BRANCH_STACK is enabled then samples are returned
with the format { u64 from, to, flags } but the flags layout
is not specified.
This field has the type struct perf_branch_entry; move this
definition into include/uapi/linux/perf_event.h so
It's been a month, are there any objections to these perf_event ABI
documentation updates?
Vince
On Thu, 25 Jul 2013, Vince Weaver wrote:
>
> This clarifies some of the ABI, as there has been some confusion
> and minor breakages lately. Most notably it documents that as
On Fri, 23 Aug 2013, Borislav Petkov wrote:
> Maybe this makes it more understandable for you but this is beside the
> point.
Understandability doesn't matter?
> But I have to say the reversed thing above does sound confusing, now
> that I'm looking at the code. Actually, at the time we discusse
I'm running the trinity fuzzer on my ARM Pandaboard, Linux 3.11-rc4
Trinity got stuck with these messages being logged. As far as I can
tell trinity-child1 wasn't doing anything that interesting when it got
stuck.
Hopefully I picked the right group to cc: it looks like it is stuck
in __schedul
98199] Code: bad PC value
[ 8111.001495] ---[ end trace 0e6c892fae28bee4 ]---/* log_to_code output from out4 */
/* by Vince Weaver
#include
#include
#include
#include
#include
#include
#include
#include
#include
int fd[1024];
struct perf_event_attr pe[1024];
char *mmap_result[1024];
#d
On Mon, 5 Aug 2013, Vince Weaver wrote:
> My perf_fuzzer quickly triggers this oops on my ARM Cortex A9 pandaboard
> running Linux 3.11-rc4.
>
> Below is the oops, I've attached a simple C test case that triggers the
> bug.
Also, if it helps, the disassembled code in ques
On Wed, 7 Aug 2013, Will Deacon wrote:
> Ok, so the following quick hack below should solve the issue (can you confirm
> it please, since I don't have access to any hardware atm?)
>
> We should revisit this for 3.12 though, because I'm not sure that our
> validation code even does the right thing
On Wed, 7 Aug 2013, Vince Weaver wrote:
> On Wed, 7 Aug 2013, Will Deacon wrote:
>
> > Ok, so the following quick hack below should solve the issue (can you
> > confirm
> > it please, since I don't have access to any hardware atm?)
> >
> > We should
k below should solve the issue (can you
> > confirm
> > it please, since I don't have access to any hardware atm?)
>
> It works for me when running Vince's test case.
>
> Tested-by: Mark Rutland
I've also tested it and the fix works for the various test c
Hello
I don't have time to come up with a test case right now, but I've
applied the patch to fix the oops from two days ago, and re-ran
my perf_fuzzer tool and it immediately came up with another issue on ARM.
This is an ARM Pandaboard running 3.11-rc4 with the one-line
oops fix from the other thr
k to make sure both are
really necessary.
I'll try this patch and see if it fixes things, thanks.
Vince
/* log_to_code output from ./new_oops.bisect15 */
/* by Vince Weaver
#include
#include
#include
#include
#include
#include
#include
#include
#include
int fd[1024];
struct perf_event_a
+ return -ENOENT;
> +
> + mapping = (*event_map)[config];
> return mapping == HW_OP_UNSUPPORTED ? -ENOENT : mapping;
> }
I've tested this patch and my testcase no longer causes the kernel to
oops, so
Tested-by: Vince Weaver
Thanks,
Vince
--
To unsubscribe fr
On Wed, 7 Aug 2013, Vince Weaver wrote:
> On Wed, 7 Aug 2013, Stephen Boyd wrote:
>
> > ---8<
> >
> > diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
> > index d9f5cd4..21f7790 100644
> > --- a/arch/arm/kernel/perf_event.c
On Thu, 8 Aug 2013, Will Deacon wrote:
> On the flip side, the good news is that we know the problem is there. We're
> probably generating interrupts at some horrendous rate for the lock-up
> are you running your fuzzer as root?
No, I'm running the fuzzer as a regular user.
> Also, is your f
On Fri, 19 Jul 2013, tip-bot for Runzhen Wang wrote:
> perf tools: Make Power7 events available for perf
>
> This patch makes all the POWER7 events available in sysfs. So we can
> instead specify these as:
>
> $ size arch/powerpc/perf/power7-pmu.o
>text data bss dec hex
On Mon, 22 Jul 2013, Andi Kleen wrote:
> From: Andi Kleen
>
> Add a precise qualifier, like cpu/event=0x3c,precise=1/
So you're adding this to "events/" but not to "format/"?
This breaks the ABI, which specifies that the only fields
that can appear in a sysfs events specifier must exist under
1 - 100 of 804 matches
Mail list logo
