On 2016/9/21 11:48, Wang Nan wrote:
Before this patch perf panic if kptr_restrict set to 1 and perf is owned
by root with suid set:
$ whoami
wangnan
$ ls -l ./perf
-rwsr-xr-x 1 root root 19781908 Sep 21 19:29 /home/wangnan/perf
$ cat /proc/sys/kernel/kptr_restrict
1
$ cat /proc/s
On 2016/6/17 0:48, Arnaldo Carvalho de Melo wrote:
Em Thu, Jun 16, 2016 at 08:02:41AM +, Wang Nan escreveu:
With '--dry-run', 'perf record' doesn't do reall recording. Combine with
llvm.dump-obj option, --dry-run can be used to help compile BPF objects for
embedded platform.
So these are
On 2016/6/17 5:47, Arnaldo Carvalho de Melo wrote:
Em Wed, Jun 15, 2016 at 02:23:34AM +, Wang Nan escreveu:
Before this patch, when using overwritable ring buffer on an old
kernel, error message is misleading:
# ~/perf record -m 1 -e raw_syscalls:*/overwrite/ -a
Error:
The raw_sysca
On 2016/6/17 4:59, Arnaldo Carvalho de Melo wrote:
Em Wed, Jun 15, 2016 at 02:23:35AM +, Wang Nan escreveu:
When see POLLERR or POLLHUP, unmap ring buffer from both the main
evlist and overwrite evlist.
When you use an auxiliary evlist this makes evlist->parent be different
than evlist, r
On 2016/6/20 17:18, Jiri Olsa wrote:
On Mon, Jun 20, 2016 at 02:14:01PM +0530, Madhavan Srinivasan wrote:
When decoding the perf_regs mask in regs_dump__printf(),
we loop through the mask using find_first_bit and find_next_bit functions.
"mask" is of type "u64", but sent as a "unsigned long *"
On 2016/6/21 4:36, Arnaldo Carvalho de Melo wrote:
Em Mon, Jun 20, 2016 at 10:47:19AM +, Wang Nan escreveu:
An auxiliary evlist is created by perf_evlist__new_aux() using an
existing evlist as its parent. An auxiliary evlist can have its own
'struct perf_mmap', but can't have any other dat
On 2016/6/20 22:38, Arnaldo Carvalho de Melo wrote:
Em Mon, Jun 20, 2016 at 11:29:13AM +0800, Wangnan (F) escreveu:
On 2016/6/17 0:48, Arnaldo Carvalho de Melo wrote:
Em Thu, Jun 16, 2016 at 08:02:41AM +, Wang Nan escreveu:
[SNIP]
About fallback, if user explicitly uses '.o'
On 2016/6/21 0:22, Alexei Starovoitov wrote:
On Mon, Jun 20, 2016 at 11:38:18AM -0300, Arnaldo Carvalho de Melo wrote:
Em Mon, Jun 20, 2016 at 11:29:13AM +0800, Wangnan (F) escreveu:
On 2016/6/17 0:48, Arnaldo Carvalho de Melo wrote:
Em Thu, Jun 16, 2016 at 08:02:41AM +, Wang Nan
On 2016/6/22 5:05, Arnaldo Carvalho de Melo wrote:
Em Mon, Jun 20, 2016 at 10:47:20AM +, Wang Nan escreveu:
Improve test backward
[SNIP]
diff --git a/tools/perf/tests/backward-ring-buffer.c
b/tools/perf/tests/backward-ring-buffer.c
index d9ba991..76e34c0 100644
--- a/tools/perf/tests
On 2016/9/22 23:41, Arnaldo Carvalho de Melo wrote:
Em Wed, Sep 21, 2016 at 03:56:20AM +, Wang Nan escreveu:
Before this patch perf panic if kptr_restrict set to 1 and perf is owned
by root with suid set:
$ whoami
wangnan
$ ls -l ./perf
-rwsr-xr-x 1 root root 19781908 Sep 21 19:29
On 2016/9/24 23:16, Alexei Starovoitov wrote:
On Fri, Sep 23, 2016 at 12:49:47PM +, Wang Nan wrote:
This patch set is the first step to implement features I announced
in LinuxCon NA 2016. See page 31 of:
http://events.linuxfoundation.org/sites/events/files/slides/Performance%20Monitori
On 2016/9/27 7:58, Arnaldo Carvalho de Melo wrote:
Le 26 sept. 2016 8:47 PM, "Alexei Starovoitov"
mailto:alexei.starovoi...@gmail.com>> a
écrit :
>
> On Mon, Sep 26, 2016 at 09:49:30AM +0800, Wangnan (F) wrote:
> >
> >
> > On 2016/9/24 23:16, Alexe
On 2016/7/30 2:05, Brendan Gregg wrote:
On Tue, Jul 19, 2016 at 4:20 PM, Brendan Gregg wrote:
When perf is performing hrtimer-based sampling, this tracepoint can be used
by BPF to run additional logic on each sample. For example, BPF can fetch
stack traces and frequency count them in kernel c
On 2016/9/13 5:15, Arnaldo Carvalho de Melo wrote:
Em Mon, Sep 12, 2016 at 04:07:42PM -0300, Arnaldo Carvalho de Melo escreveu:
Em Mon, Sep 12, 2016 at 12:54:29PM +, Wang Nan escreveu:
Some mmap related macros have different values for different
architectures. This patch introduces uapi m
On 2016/9/14 17:28, Naveen N. Rao wrote:
On 2016/09/12 06:15PM, Arnaldo Carvalho de Melo wrote:
Em Mon, Sep 12, 2016 at 04:07:42PM -0300, Arnaldo Carvalho de Melo escreveu:
Em Mon, Sep 12, 2016 at 12:54:29PM +, Wang Nan escreveu:
Some mmap related macros have different values for differe
On 2016/9/14 18:00, Naveen N. Rao wrote:
On 2016/09/14 05:36PM, Wang Nan wrote:
On 2016/9/14 17:28, Naveen N. Rao wrote:
On 2016/09/12 06:15PM, Arnaldo Carvalho de Melo wrote:
Em Mon, Sep 12, 2016 at 04:07:42PM -0300, Arnaldo Carvalho de Melo escreveu:
Em Mon, Sep 12, 2016 at 12:54:29PM +0
On 2016/9/14 18:46, Naveen N. Rao wrote:
On 2016/09/14 06:23PM, Wang Nan wrote:
On 2016/9/14 18:00, Naveen N. Rao wrote:
On 2016/09/14 05:36PM, Wang Nan wrote:
On 2016/9/14 17:28, Naveen N. Rao wrote:
On 2016/09/12 06:15PM, Arnaldo Carvalho de Melo wrote:
Em Mon, Sep 12, 2016 at 04:07:42P
perf top comsumes too much memory than it need.
Using following commands:
# yes '' > /dev/null
# perf top -e raw_syscalls:sys_enter
System will quickly become unresponsive because of out of memory.
Using GDB I find two call stacks of malloc. See below.
[call stack 1]
#0 __GI___libc_malloc
On 2016/8/5 22:12, Arnaldo Carvalho de Melo wrote:
Em Fri, Aug 05, 2016 at 06:58:12PM +0800, Wangnan (F) escreveu:
perf top comsumes too much memory than it need.
Using following commands:
# yes '' > /dev/null
# perf top -e raw_syscalls:sys_enter
System will quickly become
On 2017/11/1 18:03, Namhyung Kim wrote:
On Wed, Nov 01, 2017 at 05:53:27AM +, Wang Nan wrote:
The meaning of perf record's "overwrite" option and many "overwrite" in
source code are not clear. In perf's code, the 'overwrite' has 2 meanings:
1. Make ringbuffer readonly (perf_evlist__mmap_
On 2017/11/1 17:49, Namhyung Kim wrote:
Hi,
On Wed, Nov 01, 2017 at 05:53:26AM +, Wang Nan wrote:
perf record backward recording doesn't work as we expected: it never
overwrite when ring buffer full.
Test:
(Run a busy printing python task background like this:
while True:
print
On 2017/11/1 20:00, Namhyung Kim wrote:
On Wed, Nov 01, 2017 at 06:32:50PM +0800, Wangnan (F) wrote:
On 2017/11/1 17:49, Namhyung Kim wrote:
Hi,
On Wed, Nov 01, 2017 at 05:53:26AM +, Wang Nan wrote:
perf record backward recording doesn't work as we expected: it never
overwrite
On 2017/11/1 20:39, Jiri Olsa wrote:
On Wed, Nov 01, 2017 at 08:10:49PM +0800, Wangnan (F) wrote:
SNIP
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index c6c891e154a6..27ebe355e794 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -838,6 +838,11
On 2017/11/1 21:26, Liang, Kan wrote:
The meaning of perf record's "overwrite" option and many "overwrite" in
source code are not clear. In perf's code, the 'overwrite' has 2 meanings:
1. Make ringbuffer readonly (perf_evlist__mmap_ex's argument).
2. Set evsel's "backward" attribute (in app
On 2017/11/1 22:22, Liang, Kan wrote:
On 2017/11/1 21:26, Liang, Kan wrote:
The meaning of perf record's "overwrite" option and many "overwrite"
in source code are not clear. In perf's code, the 'overwrite' has 2 meanings:
1. Make ringbuffer readonly (perf_evlist__mmap_ex's argument).
2.
On 2017/11/1 23:04, Liang, Kan wrote:
On 2017/11/1 22:22, Liang, Kan wrote:
On 2017/11/1 21:26, Liang, Kan wrote:
The meaning of perf record's "overwrite" option and many "overwrite"
in source code are not clear. In perf's code, the 'overwrite' has 2
meanings:
1. Make ringbuffer readonl
On 2017/11/1 21:57, Liang, Kan wrote:
On 2017/11/1 20:00, Namhyung Kim wrote:
On Wed, Nov 01, 2017 at 06:32:50PM +0800, Wangnan (F) wrote:
On 2017/11/1 17:49, Namhyung Kim wrote:
Hi,
On Wed, Nov 01, 2017 at 05:53:26AM +, Wang Nan wrote:
perf record backward recording doesn't wo
On 2017/11/6 16:52, Michal Hocko wrote:
On Mon 06-11-17 15:04:40, Bob Liu wrote:
On Mon, Nov 6, 2017 at 11:36 AM, Wang Nan wrote:
tlb_gather_mmu(&tlb, mm, 0, -1) means gathering all virtual memory space.
In this case, tlb->fullmm is true. Some archs like arm64 doesn't flush
TLB when tlb->ful
On 2017/11/6 18:40, Michal Hocko wrote:
On Mon 06-11-17 17:59:54, Wangnan (F) wrote:
On 2017/11/6 16:52, Michal Hocko wrote:
On Mon 06-11-17 15:04:40, Bob Liu wrote:
On Mon, Nov 6, 2017 at 11:36 AM, Wang Nan wrote:
tlb_gather_mmu(&tlb, mm, 0, -1) means gathering all virtual memory s
On 2015/8/28 15:05, Wang Nan wrote:
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index ef5fde6..24c8b63 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -3090,6 +3090,7 @@ int cmd_trace(int argc, const char **argv, const char
*prefix __maybe_u
On 2015/8/29 8:45, Alexei Starovoitov wrote:
On 8/28/15 12:06 AM, Wang Nan wrote:
his patch adds a new trace event to establish infrastruction for bpf to
output data to perf. Userspace perf tools can detect and use this event
as using the existing tracepoint events.
New bpf trace event entry
On 2015/8/29 9:34, Alexei Starovoitov wrote:
On 8/28/15 6:19 PM, Wangnan (F) wrote:
For me, I use bpf_output_trace_data() to output information like PMU
count
value. Perf is the only receiver, so global collector is perfect.
Could you
please describe your usecase in more detail?
there is
On 2015/8/29 10:22, Alexei Starovoitov wrote:
On 8/28/15 7:15 PM, Wangnan (F) wrote:
I'd like to see whether it is possible to create dynamic tracepoints so
different receivers can listen on different tracepoints.
see my proposal A. I think ftrace instances might work for this.
I&
On 2015/8/29 10:49, Alexei Starovoitov wrote:
On 8/28/15 7:36 PM, Wangnan (F) wrote:
For current patch 32/32, I think it is useful enough for some simple
cases,
and we have already start using it internally. What about keep it as
what it
is now and create a independent method for your
On 2015/8/31 21:59, Arnaldo Carvalho de Melo wrote:
Em Fri, Aug 28, 2015 at 05:25:27PM -0700, Alexei Starovoitov escreveu:
On 8/28/15 12:05 AM, Wang Nan wrote:
This time I adjust all Cc and Link field in each patch.
Four new patches (1,2,3,12/32) is newly introduced for fixing a bug
related t
On 2015/9/1 4:43, Arnaldo Carvalho de Melo wrote:
Em Sat, Aug 29, 2015 at 04:21:57AM +, Wang Nan escreveu:
From: He Kuang
arch_get_reg_info() is a helper function which converts register name
like "%rax" to offset of a register in 'struct pt_regs', which is
required by BPF prologue gener
On 2015/8/29 12:21, Wang Nan wrote:
diff --git a/tools/perf/tests/Build b/tools/perf/tests/Build
index c1518bd..8c98409 100644
--- a/tools/perf/tests/Build
+++ b/tools/perf/tests/Build
@@ -32,7 +32,14 @@ perf-y += sample-parsing.o
perf-y += parse-no-sample-id-all.o
perf-y += kmod-path.o
p
On 2015/9/1 14:24, Adrian Hunter wrote:
On 01/09/15 08:56, Wang Nan wrote:
I hit following building error randomly:
Random presumably because there is a race to use/create the directory by
different make jobs (i.e. -j option).
Yes, I use -j 160 :)
...
/bin/sh: /path/to/kernel/buildperf
On 2015/9/1 3:20, Arnaldo Carvalho de Melo wrote:
Em Sat, Aug 29, 2015 at 04:21:36AM +, Wang Nan escreveu:
If parse_events__scanner() collects no entry, perf_evlist__last(evlist)
is invalid. Then setting of cmdline_group_boundary touches invalid.
It could happend in currect BPF implementa
On 2015/9/1 18:38, Jiri Olsa wrote:
On Mon, Aug 31, 2015 at 04:20:03PM -0300, Arnaldo Carvalho de Melo wrote:
Em Sat, Aug 29, 2015 at 04:21:36AM +, Wang Nan escreveu:
If parse_events__scanner() collects no entry, perf_evlist__last(evlist)
is invalid. Then setting of cmdline_group_boundary
On 2015/9/1 19:47, 平松雅巳 / HIRAMATU，MASAMI wrote:
From: Wang Nan [mailto:wangn...@huawei.com]
regs_query_register_offset() is a helper function which converts
register name like "%rax" to offset of a register in 'struct pt_regs',
which is required by BPF prologue generator. Since the function i
On 2015/10/12 20:02, Peter Zijlstra wrote:
On Mon, Oct 12, 2015 at 09:02:42AM +, Kaixu Xia wrote:
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -483,6 +483,8 @@ struct perf_event {
perf_overflow_handler_t overflow_handler;
void
On 2015/10/13 3:29, Alexei Starovoitov wrote:
On 10/12/15 2:02 AM, Kaixu Xia wrote:
+extern const struct bpf_func_proto bpf_perf_event_sample_enable_proto;
+extern const struct bpf_func_proto bpf_perf_event_sample_disable_proto;
externs are unnecessary. Just make them static.
Also I prefer s
On 2015/10/13 11:39, Alexei Starovoitov wrote:
On 10/12/15 8:27 PM, Wangnan (F) wrote:
Then how to avoid racing? For example, when one core disabling all
events
in a map, another core is enabling all of them. This racing may causes
sereval
perf events in a map dump samples while other events
On 2015/10/13 12:16, Alexei Starovoitov wrote:
On 10/12/15 8:51 PM, Wangnan (F) wrote:
why 'set disable' is needed ?
the example given in cover letter shows the use case where you want
to receive samples only within sys_write() syscall.
The example makes sense, but sys_write() is
On 2015/10/13 13:15, Alexei Starovoitov wrote:
On 10/12/15 9:34 PM, Wangnan (F) wrote:
On 2015/10/13 12:16, Alexei Starovoitov wrote:
On 10/12/15 8:51 PM, Wangnan (F) wrote:
why 'set disable' is needed ?
the example given in cover letter shows the use case where you want
On 2015/10/13 18:54, He Kuang wrote:
hi, Alexei
What about using similar
implementation
like PERF_EVENT_IOC_SET_OUTPUT, creating a new ioctl like
PERF_EVENT_IOC_SET_ENABLER,
then let perf to select an event as 'enabler', then BPF can still
control one atomic
variable to enable/disable a set o
On 2015/9/1 23:54, 平松雅巳 / HIRAMATU，MASAMI wrote:
From: Arnaldo Carvalho de Melo [mailto:a...@redhat.com]
Em Tue, Sep 01, 2015 at 11:47:41AM +, 平松雅巳 / HIRAMATU，MASAMI escreveu:
From: Wang Nan [mailto:wangn...@huawei.com]
regs_query_register_offset() is a helper function which converts
reg
Hi Namhyung,
Thanks for this patchset.
Could you plase have a look at patch 5/27 and 6/27 in my newest pull
request?
These 2 patches utilize new probing API to create probe point and collect
probe_trace_events. I'm not very sure I fully understand your design
principle,
especially the cleanup
On 2015/9/7 21:03, Jiri Olsa wrote:
On Mon, Sep 07, 2015 at 12:51:55PM +, Wang Nan wrote:
Commit e1e499aba570a2ea84d29822b7ea637ac41d9a51 (perf tools: Add
processor socket info to hist_entry and addr_location) reads env->cpu
array for each sample using index al.cpu. However, al.cpu can be
On 2015/9/7 20:51, Wang Nan wrote:
[SNIP]
Although theoretically CPU_TOPOLOGY feature should always be selected by
'perf record', I did generate a perf.data without that feature. It has
header like this:
# perf report -i ./bad.perf.data --header-only
#
# captured on: Thu Jan
On 2015/9/8 15:37, Jiri Olsa wrote:
On Mon, Sep 07, 2015 at 09:27:26PM +0800, Wangnan (F) wrote:
SNIP
I found the problem.
perf relies on build_cpu_topology() to fetch CPU_TOPOLOGY from sysfs. It
depend on
the existance of
/sys/devices/system/cpu/cpu%d/topology/core_siblings_list
However
On 2015/10/14 23:45, Namhyung Kim wrote:
On Wed, Oct 14, 2015 at 12:41:20PM +, Wang Nan wrote:
This patch provides infrastructure for passing source files to --event
directly using:
# perf record --event bpf-file.c command
This patch does following works:
1) Allow passing '.c' file
On 2015/10/15 13:26, Namhyung Kim wrote:
On Wed, Oct 14, 2015 at 12:41:27PM +, Wang Nan wrote:
From: He Kuang
This patch generates prologue for a BPF program which fetch arguments
for it. With this patch, the program can have arguments as follow:
SEC("lock_page=__lock_page page->flags
On 2015/10/14 23:48, Namhyung Kim wrote:
On Wed, Oct 14, 2015 at 12:41:21PM +, Wang Nan wrote:
This patch replaces the original toy BPF program with previous introduced
bpf-script-example.c. Dynamically embedded it into 'llvm-src.c'.
The newly introduced BPF program attaches a BPF program
On 2015/10/18 4:35, Alexei Starovoitov wrote:
On 10/17/15 3:48 AM, Wang Nan wrote:
In these 7 patches:
1. perf is able to put values into map:
# perf record -e mybpf.c/maps.values.value=1234/ ...
2. perf is able to control different slots in a map separately:
# perf record -e
mybp
On 2015/10/20 23:15, Arnaldo Carvalho de Melo wrote:
Em Tue, Oct 20, 2015 at 12:12:55PM -0300, Arnaldo Carvalho de Melo escreveu:
Em Wed, Oct 14, 2015 at 12:41:14PM +, Wang Nan escreveu:
By introducing new rules in tools/perf/util/parse-events.[ly], this
patch enables 'perf record --event
On 2015/10/20 23:42, Arnaldo Carvalho de Melo wrote:
Em Tue, Oct 20, 2015 at 12:15:58PM -0300, Arnaldo Carvalho de Melo escreveu:
Em Tue, Oct 20, 2015 at 12:12:55PM -0300, Arnaldo Carvalho de Melo escreveu:
Em Wed, Oct 14, 2015 at 12:41:14PM +, Wang Nan escreveu:
Managed after running:
On 2015/10/21 3:12, Arnaldo Carvalho de Melo wrote:
Em Wed, Oct 14, 2015 at 12:41:15PM +, Wang Nan escreveu:
This patch introduces bpf__{un,}probe() functions to enable callers to
create kprobe points based on section names a BPF program. It parses
the section names in the program and crea
On 2015/10/21 3:12, Arnaldo Carvalho de Melo wrote:
Em Wed, Oct 14, 2015 at 12:41:15PM +, Wang Nan escreveu:
This patch introduces bpf__{un,}probe() functions to enable callers to
create kprobe points based on section names a BPF program. It parses
the section names in the program and crea
On 2015/10/21 18:20, Ingo Molnar wrote:
* He Kuang wrote:
ping and add a...@plumgrid.com, what's your opinion on this?
Firstly, two days isn't nearly enough for a 'review timeout', secondly, have you
seen the kbuild test reports?
Thirdly, I suspect others will do a deeper review, but even
On 2015/10/21 18:01, He Kuang wrote:
hi, Alexei
I've tested the sample in next patch and it works well. I think more
work on
the perf side needs to be done for parsing PERF_COUNT_SW_BPF_OUTPUT
event type,
are you working on that?
Thank you.
We need to add something into parse-event.y/l t
On 2015/10/21 17:12, Peter Zijlstra wrote:
On Tue, Oct 20, 2015 at 03:53:02PM -0700, Alexei Starovoitov wrote:
On 10/20/15 12:22 AM, Kaixu Xia wrote:
diff --git a/kernel/events/core.c b/kernel/events/core.c
index b11756f..5219635 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@
On 2015/10/21 19:33, Peter Zijlstra wrote:
On Wed, Oct 21, 2015 at 06:31:04PM +0800, xiakaixu wrote:
The RFC patch set contains the necessary commit log [1].
That's of course the wrong place, this should be in the patch's
Changelog. It doesn't become less relevant.
In some scenarios we don
On 2015/10/21 16:09, Namhyung Kim wrote:
Hi Frederic,
On Tue, Oct 20, 2015 at 07:21:16PM +0200, Frederic Weisbecker wrote:
On Tue, Oct 20, 2015 at 10:06:51AM -0300, Arnaldo Carvalho de Melo wrote:
Em Tue, Oct 20, 2015 at 02:19:50PM +0200, Frederic Weisbecker escreveu:
On Tue, Oct 20, 2015 a
On 2015/10/21 19:56, Peter Zijlstra wrote:
On Wed, Oct 21, 2015 at 07:34:28PM +0800, Wangnan (F) wrote:
If you want to actually disable the event: pmu->stop() will make it
stop, and you can restart using pmu->start().xiezuo
I also prefer totally disabling event because our goal is to
On 2015/10/21 16:53, Namhyung Kim wrote:
Hi,
On Wed, Oct 14, 2015 at 12:41:37PM +, Wang Nan wrote:
From: He Kuang
This patch adds new bison rules for specifying an alias name to a perf
event, which allows cmdline refer to previous defined perf event through
its name. With this patch use
On 2015/10/21 20:17, Peter Zijlstra wrote:
On Wed, Oct 21, 2015 at 07:49:34PM +0800, Wangnan (F) wrote:
If our task is sampling cycle events during a function is running,
and if two cores start that function overlap:
Time: ...A
Core 0: sys_write
Hi Alexei,
On 2015/10/21 21:42, Wangnan (F) wrote:
One alternative solution I can image is to attach a BPF program
at sampling like kprobe, and return 0 if we don't want sampling
take action. Thought?
Do you think attaching BPF programs to sampling is an acceptable idea?
Than
On 2015/10/22 0:57, Peter Zijlstra wrote:
On Wed, Oct 21, 2015 at 11:06:47PM +0800, pi3orama wrote:
So explain; how does this eBPF stuff work.
I think I get your point this time, and let me explain the eBPF stuff to you.
You are aware that BPF programmer can break the system in this way:
A=
On 2015/10/22 11:09, Alexei Starovoitov wrote:
On 10/21/15 6:56 PM, Wangnan (F) wrote:
One alternative solution I can image is to attach a BPF program
at sampling like kprobe, and return 0 if we don't want sampling
take action. Thought?
Do you think attaching BPF programs to sampling
After applying this patch I'm unable to use perf passing perf_event
again like this:
# perf record -a -e evt=cycles -e
./test_config_map.c/maps.pmu_map.event=evt/ --exclude-perf ls
With -v it output:
...
adding perf_bpf_probe:func_write
adding perf_bpf_probe:func_write to 0x367d6a0
add bpf
On 2015/10/22 13:00, Alexei Starovoitov wrote:
On 10/21/15 9:49 PM, Wangnan (F) wrote:
After applying this patch I'm unable to use perf passing perf_event
again like this:
please do not top post and trim your replies.
# perf record -a -e evt=cycles -e
./test_config_
On 2015/10/22 6:58, Alexei Starovoitov wrote:
Fix safety checks for bpf_perf_event_read():
- only non-inherited events can be added to perf_event_array map
(do this check statically at map insertion time)
- dynamically check that event is local and !pmu->count
Otherwise buggy bpf program can
On 2015/10/22 15:16, Namhyung Kim wrote:
Hi,
On Wed, Oct 21, 2015 at 10:00 PM, Wangnan (F) wrote:
On 2015/10/21 16:53, Namhyung Kim wrote:
Hi,
On Wed, Oct 14, 2015 at 12:41:37PM +, Wang Nan wrote:
From: He Kuang
This patch adds new bison rules for specifying an alias name to a
On 2015/10/22 14:21, Alexei Starovoitov wrote:
On 10/21/15 10:31 PM, Wangnan (F) wrote:
+if ((attr->type != PERF_TYPE_RAW &&
+ !(attr->type == PERF_TYPE_SOFTWARE &&
+ attr->config == PERF_COUNT_SW_BPF_OUTPUT) &&
+
On 2015/10/22 15:39, Ingo Molnar wrote:
* Wangnan (F) wrote:
[SNIP]
In summary, your either-or logic doesn't hold in BPF world. A BPF
program can only access perf event in a highly restricted way. We
don't allow it calling perf_event_read_local() across core, so it
can't
On 2015/10/22 15:53, Namhyung Kim wrote:
On Thu, Oct 22, 2015 at 4:29 PM, Wangnan (F) wrote:
[SNIP]
I understand the need of using aliases but I think it's more natural
to use event name for simple cases..
I will consider this. However, if we allow using event name directly like
On 2015/10/22 17:06, Peter Zijlstra wrote:
On Wed, Oct 21, 2015 at 02:19:49PM -0700, Alexei Starovoitov wrote:
Urgh, that's still horridly inconsistent. Can we please come up with a
consistent interface to perf?
My suggestion was to do ioctl(enable/disable) of events from userspace
after rec
On 2015/10/22 6:58, Alexei Starovoitov wrote:
[SNIP]
diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
index e3cfe46b074f..75529cc94304 100644
--- a/kernel/bpf/arraymap.c
+++ b/kernel/bpf/arraymap.c
@@ -294,10 +294,11 @@ static void *perf_event_fd_array_get_ptr(struct bpf_map
*map, i
On 2015/9/2 4:11, Arnaldo Carvalho de Melo wrote:
Em Sat, Aug 29, 2015 at 04:22:02AM +, Wang Nan escreveu:
Before this patch, add_perf_probe_events() init symbol maps only for
uprobe if the first 'struct perf_probe_event' passed to it is a uprobe
event. This is a trick because 'perf probe'
On 2015/9/2 10:53, Wang Nan wrote:
Similar to patch 'perf tools: Don't set cmdline_group_boundary if no
evsel is collected', in case when parser collects no evsel (at this
point it shouldn't happen), parse_events__set_leader() is not safe.
This patch checks list_empty becore calling __perf_evl
On 2015/9/2 12:32, Namhyung Kim wrote:
Hi,
On Sat, Aug 29, 2015 at 04:21:41AM +, Wang Nan wrote:
This patch drops struct __event_package structure. Instead, it adds
trace_probe_event into 'struct perf_probe_event'.
trace_probe_event information gives further patches a chance to access
ac
On 2015/9/2 13:57, 平松雅巳 / HIRAMATU，MASAMI wrote:
From: Wang Nan [mailto:wangn...@huawei.com]
Similar to patch 'perf tools: Don't set cmdline_group_boundary if no
evsel is collected', in case when parser collects no evsel (at this
point it shouldn't happen), parse_events__set_leader() is not sa
Sorry, forget to CC kernel mailing list...
On 2015/9/2 14:49, Wang Nan wrote:
If parse_events__scanner() collects no entry, perf_evlist__last(evlist)
is invalid.
Although it shouldn't happen at this point, before calling
perf_evlist__last(), we should ensure the list is not empty for safety
rea
On 2015/9/2 18:34, Will Deacon wrote:
On Mon, Aug 31, 2015 at 09:16:28PM +0100, Arnaldo Carvalho de Melo wrote:
Em Sat, Aug 29, 2015 at 03:16:52AM +, He Kuang escreveu:
This patch implements arch_get_reg_info() for arm64 to enable
HAVE_BPF_PROLOGUE feature. For arm64, structure pt_regs is
On 2015/10/19 22:53, Arnaldo Carvalho de Melo wrote:
Em Mon, Oct 19, 2015 at 11:42:31PM +0900, Namhyung Kim escreveu:
Hi,
On Wed, Oct 14, 2015 at 12:41:32PM +, Wang Nan wrote:
This patch enforces existing LLVM test, makes it compile more than one
BPF source file. The compiled results are
Hi Namhyung and Arnaldo,
I changed my testing related patches in my local git tree. All
changed combined together is at the end of this mail. I remove
all stderr output, and improve debug message. Please have a look
at it.
Thank you.
diff --git a/tools/perf/tests/bpf.c b/tools/perf/tests/bpf.c
Hi Arnaldo,
On 2015/10/6 5:03, Arnaldo Carvalho de Melo wrote:
From: Arnaldo Carvalho de Melo
Which is the most common default found in other similar tools.
Could you please show me some example about "other similar tools"?
For me, in most of the case I prefer callee order because most of my
On 2015/10/23 8:10, Alexei Starovoitov wrote:
Fix safety checks for bpf_perf_event_read():
- only non-inherited events can be added to perf_event_array map
(do this check statically at map insertion time)
- dynamically check that event is local and !pmu->count
Otherwise buggy bpf program can
On 2015/10/23 8:10, Alexei Starovoitov wrote:
Fix safety checks for bpf_perf_event_read():
- only non-inherited events can be added to perf_event_array map
(do this check statically at map insertion time)
- dynamically check that event is local and !pmu->count
Otherwise buggy bpf program can
On 2015/10/17 18:48, Wang Nan wrote:
[SNIP]
event_bpf_file:
-PE_BPF_OBJECT
+PE_BPF_OBJECT event_bpf_config
{
struct parse_events_evlist *data = _data;
struct parse_events_error *error = data->error;
struct list_head *list;
ALLOC_LIST(list);
- ABORT_O
On 2015/10/24 1:25, Alexei Starovoitov wrote:
On 10/23/15 9:42 AM, Peter Zijlstra wrote:
On Fri, Oct 23, 2015 at 08:02:00AM -0700, Alexei Starovoitov wrote:
On 10/23/15 7:39 AM, Peter Zijlstra wrote:
On Tue, Oct 20, 2015 at 08:02:34PM -0700, Alexei Starovoitov wrote:
+static const struct bp
On 2015/10/26 14:36, Wang Nan wrote:
Many reason can make bpf_prog_load() return EINVAL. This patch utilizes
logbuf passed from user to deliver the actual reason of failure.
Without this patch, people is easy to forget fixing the "version"
section in their BPF objects.
Signed-off-by: Wang Nan
Hi Arnaldo,
On 2015/10/24 8:27, Arnaldo Carvalho de Melo wrote:
libbpf: load bpf program failed: Invalid argument
libbpf: -- BEGIN DUMP LOG ---
libbpf:
libbpf: -- END LOG --
libbpf: failed to load program 'fork=_do_fork'
libbpf: failed to load object '/tmp/foo.o'
bpf: load objects failed
event
On 2015/10/24 0:17, Arnaldo Carvalho de Melo wrote:
Em Fri, Oct 23, 2015 at 09:58:20PM +0800, pi3orama escreveu:
发自我的 iPhone
在 2015年10月23日，下午9:51，Arnaldo Carvalho de Melo 写道：
Em Fri, Oct 23, 2015 at 10:43:49AM +, Wang Nan escreveu:
Inherit bit is useless for a system wide evsel [1].
On 2015/10/26 17:25, Adrian Hunter wrote:
On 26/10/15 11:08, Wangnan (F) wrote:
evsel->system_wide is introduced by commit
bf8e8f4b832972c76d64ab2e2837a48397144887
(perf evlist: Add 'system_wide' option), but Adrian only introduced a new field
into perf, doesn't really mak
On 2015/10/26 20:24, Adrian Hunter wrote:
On 26/10/15 13:41, Wang Nan wrote:
evsel->system_wide is introduced by commit bf8e8f4b832972c76d64ab2e2837
(perf evlist: Add 'system_wide' option), which is used for mixing evsels
that aren't system-wide with ones that are [1]. However, for global
syst
On 2015/10/26 20:32, Peter Zijlstra wrote:
On Sun, Oct 25, 2015 at 09:23:36AM -0700, Alexei Starovoitov wrote:
bpf_perf_event_read() muxes of -EINVAL into return value, but it's non
ambiguous to the program whether it got an error or real counter value.
How can that be, the (u64)-EINVAL value
On 2015/10/14 20:41, Wang Nan wrote:
This patch appends new syntax to BPF object section name to support
probing at uprobe event. Now we can use BPF program like this:
SEC(
"target=/lib64/libc.so.6\n"
"libcwrite=__write"
)
int libcwrite(void *ctx)
{
return 1;
}
Where, in s
1 - 100 of 523 matches
Mail list logo
