Re: linux-next network throughput performance regression

On 11/6/15 2:18 PM, Simon Xiao wrote: The .config file used to build linux-next kernel is attached to this mail. Thanks. Failed to notice this on the first response; my brain filled in. Why linux-next tree? Can you try net-next which is more relevant for this mailing list, post the top

Re: [PATCH 04/31] perf record, bpf: Create probe points for BPF programs

On 10/20/15 1:12 PM, Arnaldo Carvalho de Melo wrote: I.e. no libbpf error (good!) but then, just an -EINVAL as the "event syntax error", which clearly isn't a syntax error, we need to tell the user that he or she needs special perfmissions for using sys_bpf():-) perfmissions? Are you coining

Re: [PATCH 04/31] perf record, bpf: Create probe points for BPF programs

On 10/20/15 1:12 PM, Arnaldo Carvalho de Melo wrote: I.e. no libbpf error (good!) but then, just an -EINVAL as the "event syntax error", which clearly isn't a syntax error, we need to tell the user that he or she needs special perfmissions for using sys_bpf():-) perfmissions? Are you coining

Re: [PATCH 2/2] perf test: Suppress libtraceevent warnings

-by: Namhyung Kim --- tools/perf/tests/parse-events.c | 14 ++ tools/perf/util/usage.c | 5 + tools/perf/util/util.h | 1 + 3 files changed, 20 insertions(+) Acked-by: David Ahern -- To unsubscribe from this list: send the line "unsubscribe linux-k

Re: [PATCH 1/2] perf test: Silence tracepoint event failures

| 2 +- tools/perf/tests/openat-syscall.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) Acked-by: David Ahern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo

Re: [PATCH 00/14] perf bench: Misc improvements

On 10/19/15 2:04 AM, Ingo Molnar wrote: tools/perf/bench/Build | 2 +- tools/perf/bench/mem-functions.c | 379 + tools/perf/bench/mem-memcpy.c | 434 -

Re: [PATCH 08/14] perf/bench/mem: Rename 'routine' to 'routine_str'

On 10/19/15 2:04 AM, Ingo Molnar wrote: @@ -128,7 +128,7 @@ static void __bench_mem_routine(struct bench_mem_info *info, int r_idx, size_t l double result_bps = 0.0; u64 result_cycles = 0; - printf("Routine %s (%s)\n", r->name, r->desc); + printf("routine %s

Re: [PATCH 06/14] perf/bench: List output formatting options on 'perf bench -h'

On 10/19/15 2:04 AM, Ingo Molnar wrote: diff --git a/tools/perf/bench/mem-functions.c b/tools/perf/bench/mem-functions.c index 33de5d57a163..d822ee0c6003 100644 --- a/tools/perf/bench/mem-functions.c +++ b/tools/perf/bench/mem-functions.c @@ -273,7 +273,7 @@ static double

Re: [PATCH 00/14] perf bench: Misc improvements

On 10/19/15 2:04 AM, Ingo Molnar wrote: tools/perf/bench/Build | 2 +- tools/perf/bench/mem-functions.c | 379 + tools/perf/bench/mem-memcpy.c | 434 -

Re: [PATCH 06/14] perf/bench: List output formatting options on 'perf bench -h'

On 10/19/15 2:04 AM, Ingo Molnar wrote: diff --git a/tools/perf/bench/mem-functions.c b/tools/perf/bench/mem-functions.c index 33de5d57a163..d822ee0c6003 100644 --- a/tools/perf/bench/mem-functions.c +++ b/tools/perf/bench/mem-functions.c @@ -273,7 +273,7 @@ static double

Re: [PATCH 08/14] perf/bench/mem: Rename 'routine' to 'routine_str'

On 10/19/15 2:04 AM, Ingo Molnar wrote: @@ -128,7 +128,7 @@ static void __bench_mem_routine(struct bench_mem_info *info, int r_idx, size_t l double result_bps = 0.0; u64 result_cycles = 0; - printf("Routine %s (%s)\n", r->name, r->desc); + printf("routine %s

Re: [PATCH 1/2] perf test: Silence tracepoint event failures

ts/openat-syscall-tp-fields.c | 2 +- tools/perf/tests/openat-syscall.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) Acked-by: David Ahern <dsah...@gmail.com> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the bo

Re: [PATCH 2/2] perf test: Suppress libtraceevent warnings

-by: Namhyung Kim <namhy...@kernel.org> --- tools/perf/tests/parse-events.c | 14 ++ tools/perf/util/usage.c | 5 + tools/perf/util/util.h | 1 + 3 files changed, 20 insertions(+) Acked-by: David Ahern <dsah...@gmail.com> -- To unsubscribe from thi

Re: [PATCH] ipv6: no addrconf for slave devices

On 10/16/15 10:12 AM, Jan Blunck wrote: On Fri, Oct 16, 2015 at 6:02 PM, David Ahern wrote: On 10/16/15 9:57 AM, Jan Blunck wrote: I don't think that enslaved ports should get network layer addresses. This is one example with a team device: for VRF devices we do want the enslaved links

Re: [PATCH] ipv6: no addrconf for slave devices

On 10/16/15 9:57 AM, Jan Blunck wrote: I don't think that enslaved ports should get network layer addresses. This is one example with a team device: for VRF devices we do want the enslaved links to have link local addresses. -- To unsubscribe from this list: send the line "unsubscribe

Re: [PATCH] ipv6: no addrconf for slave devices

On 10/16/15 9:57 AM, Jan Blunck wrote: I don't think that enslaved ports should get network layer addresses. This is one example with a team device: for VRF devices we do want the enslaved links to have link local addresses. -- To unsubscribe from this list: send the line "unsubscribe

Re: [PATCH] ipv6: no addrconf for slave devices

On 10/16/15 10:12 AM, Jan Blunck wrote: On Fri, Oct 16, 2015 at 6:02 PM, David Ahern <d...@cumulusnetworks.com> wrote: On 10/16/15 9:57 AM, Jan Blunck wrote: I don't think that enslaved ports should get network layer addresses. This is one example with a team device: for VRF devices

Re: [PATCH v9 1/4] perf,kvm/{x86,s390}: Remove dependency on uapi/kvm_perf.h

On 10/6/15 8:25 PM, Hemant Kumar wrote: @@ -358,7 +357,12 @@ static bool handle_end_event(struct perf_kvm_stat *kvm, time_diff = sample->time - time_begin; if (kvm->duration && time_diff > kvm->duration) { - char decode[DECODE_STR_LEN]; + char *decode

Re: [PATCH v9 1/4] perf,kvm/{x86,s390}: Remove dependency on uapi/kvm_perf.h

On 10/6/15 8:25 PM, Hemant Kumar wrote: @@ -358,7 +357,12 @@ static bool handle_end_event(struct perf_kvm_stat *kvm, time_diff = sample->time - time_begin; if (kvm->duration && time_diff > kvm->duration) { - char decode[DECODE_STR_LEN]; + char *decode

Re: [PATCH 5/9] perf tools: Introduce 'P' modifier

On 10/5/15 12:06 PM, Jiri Olsa wrote: The 'P' will cause the event to get maximum possible detected precise level. Following record: $ perf record -e cycles:P ... will detect maximum precise level for 'cycles' event and use it. Does the end result (which precise level is used) get saved

Re: [PATCH 5/9] perf tools: Introduce 'P' modifier

On 10/5/15 12:06 PM, Jiri Olsa wrote: The 'P' will cause the event to get maximum possible detected precise level. Following record: $ perf record -e cycles:P ... will detect maximum precise level for 'cycles' event and use it. Does the end result (which precise level is used) get saved

Re: net: panic when removing device due to vrf

On 10/1/15 4:50 PM, Sasha Levin wrote: Hi David, Commit 93a7e7e837 ("net: Remove the now unused vrf_ptr") is causing a panic whenever I unplug a network device: Cong just sent a patch. Sorry for the trouble. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the

Re: net: panic when removing device due to vrf

On 10/1/15 4:50 PM, Sasha Levin wrote: Hi David, Commit 93a7e7e837 ("net: Remove the now unused vrf_ptr") is causing a panic whenever I unplug a network device: Cong just sent a patch. Sorry for the trouble. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the

Re: [PATCH v8 1/4] perf,kvm/{x86,s390}: Remove dependency on uapi/kvm_perf.h

On 9/28/15 9:16 AM, Scott Wood wrote: On Mon, 2015-09-28 at 08:31 -0600, David Ahern wrote: On 9/28/15 7:00 AM, Alexander Yarygin wrote: diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c index fc1cffb..ef25fcf 100644 --- a/tools/perf/builtin-kvm.c +++ b/tools/perf/builtin-kvm.c

Re: [PATCH v8 1/4] perf,kvm/{x86,s390}: Remove dependency on uapi/kvm_perf.h

On 9/28/15 7:00 AM, Alexander Yarygin wrote: diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c index fc1cffb..ef25fcf 100644 --- a/tools/perf/builtin-kvm.c +++ b/tools/perf/builtin-kvm.c @@ -31,20 +31,18 @@ #include #ifdef HAVE_KVM_STAT_SUPPORT -#include #include

Re: [PATCH v8 1/4] perf,kvm/{x86,s390}: Remove dependency on uapi/kvm_perf.h

On 9/28/15 7:00 AM, Alexander Yarygin wrote: diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c index fc1cffb..ef25fcf 100644 --- a/tools/perf/builtin-kvm.c +++ b/tools/perf/builtin-kvm.c @@ -31,20 +31,18 @@ #include #ifdef HAVE_KVM_STAT_SUPPORT -#include #include

Re: [PATCH v8 1/4] perf,kvm/{x86,s390}: Remove dependency on uapi/kvm_perf.h

On 9/28/15 9:16 AM, Scott Wood wrote: On Mon, 2015-09-28 at 08:31 -0600, David Ahern wrote: On 9/28/15 7:00 AM, Alexander Yarygin wrote: diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c index fc1cffb..ef25fcf 100644 --- a/tools/perf/builtin-kvm.c +++ b/tools/perf/builtin-kvm.c

Re: [lkp] [net] 192132b9a0: -17.5% netperf.Throughput_tps

On 9/23/15 6:37 PM, Huang Ying wrote: I take it you have CONFIG_NET_VRF enabled. correct? With it disabled I see no relevant change in performance between 8f58336d3f78 and 192132b9a034. Can you confirm? The kconfig file is attached with the mail. It appears that CONFIG_NET_VRF is disabled.

Re: [lkp] [net] 192132b9a0: -17.5% netperf.Throughput_tps

On 9/20/15 7:33 PM, Huang Ying wrote: Also, this is the end patch of a series that first refactors and then adds a capability. The more relevant comparison is 8f58336d3f78 to 192132b9a034 (8f58336d3f78 is the commit before the series). Is it possible to get this test run on your system comparing

Re: [lkp] [net] 192132b9a0: -17.5% netperf.Throughput_tps

On 9/20/15 7:33 PM, Huang Ying wrote: Also, this is the end patch of a series that first refactors and then adds a capability. The more relevant comparison is 8f58336d3f78 to 192132b9a034 (8f58336d3f78 is the commit before the series). Is it possible to get this test run on your system comparing

Re: [lkp] [net] 192132b9a0: -17.5% netperf.Throughput_tps

On 9/23/15 6:37 PM, Huang Ying wrote: I take it you have CONFIG_NET_VRF enabled. correct? With it disabled I see no relevant change in performance between 8f58336d3f78 and 192132b9a034. Can you confirm? The kconfig file is attached with the mail. It appears that CONFIG_NET_VRF is disabled.

Re: [RFC resend] Perf: Trigger and dump sample info to perf.data from user space ring buffer

On 9/21/15 9:16 PM, Yunlong Song wrote: [Problem Background] We want to run perf in daemon mode and collect the traces when the exception (e.g., machine crashes, app performance goes down) appears. Perf may run for a long time (from days to weeks or even months), since we do not know when the

Re: [RFC resend] Perf: Trigger and dump sample info to perf.data from user space ring buffer

On 9/21/15 9:16 PM, Yunlong Song wrote: [Problem Background] We want to run perf in daemon mode and collect the traces when the exception (e.g., machine crashes, app performance goes down) appears. Perf may run for a long time (from days to weeks or even months), since we do not know when the

Re: [lkp] [net] 192132b9a0: -17.5% netperf.Throughput_tps

On 9/20/15 7:33 PM, Huang Ying wrote: Clarification: The reproduce file shows 128 instances of 'netperf -t TCP_CRR -c -C -l 300 -H 127.0.0.1' without an '&' on the end. Does that mean these 128 commands are run serially? Sorry. It's a script bug, there should be a "&" on the end. Will fix

Re: [lkp] [net] 192132b9a0: -17.5% netperf.Throughput_tps

On 9/20/15 6:30 AM, kernel test robot wrote: FYI, we noticed the below changes on https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master commit 192132b9a034d87566294be0fba5f8f75c2cf16b ("net: Add support for VRFs to inetpeer cache")

Re: [lkp] [net] 192132b9a0: -17.5% netperf.Throughput_tps

On 9/20/15 6:30 AM, kernel test robot wrote: FYI, we noticed the below changes on https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master commit 192132b9a034d87566294be0fba5f8f75c2cf16b ("net: Add support for VRFs to inetpeer cache")

Re: [lkp] [net] 192132b9a0: -17.5% netperf.Throughput_tps

On 9/20/15 7:33 PM, Huang Ying wrote: Clarification: The reproduce file shows 128 instances of 'netperf -t TCP_CRR -c -C -l 300 -H 127.0.0.1' without an '&' on the end. Does that mean these 128 commands are run serially? Sorry. It's a script bug, there should be a "&" on the end. Will fix

Re: [PATCH] tools lib api fs: Store tracing mountpoint for better error message

On 9/19/15 8:47 AM, Jiri Olsa wrote: diff --git a/tools/lib/api/fs/tracing_path.c b/tools/lib/api/fs/tracing_path.c index 38aca2dd1946..0406a7d5c891 100644 --- a/tools/lib/api/fs/tracing_path.c +++ b/tools/lib/api/fs/tracing_path.c @@ -12,12 +12,14 @@ #include "tracing_path.h" +char

Re: [linux-next] oops in ip_route_input_noref

On 9/18/15 5:06 PM, Andrew Morton wrote: I've been hitting this as well. An oops on boot in ip_route_input_slow(), here: Fixed in net-next. bde6f9ded1bd37ff27a042dcb968e104d92b02c1 David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to

Re: [linux-next] oops in ip_route_input_noref

On 9/18/15 5:06 PM, Andrew Morton wrote: I've been hitting this as well. An oops on boot in ip_route_input_slow(), here: Fixed in net-next. bde6f9ded1bd37ff27a042dcb968e104d92b02c1 David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to

Re: [PATCH] tools lib api fs: Store tracing mountpoint for better error message

On 9/19/15 8:47 AM, Jiri Olsa wrote: diff --git a/tools/lib/api/fs/tracing_path.c b/tools/lib/api/fs/tracing_path.c index 38aca2dd1946..0406a7d5c891 100644 --- a/tools/lib/api/fs/tracing_path.c +++ b/tools/lib/api/fs/tracing_path.c @@ -12,12 +12,14 @@ #include "tracing_path.h" +char

Re: [linux-next] oops in ip_route_input_noref

On 9/16/15 9:00 AM, Fabio Estevam wrote: On Wed, Sep 16, 2015 at 6:24 AM, Sergey Senozhatsky wrote: added by b7503e0cdb5dbec5d201aa69dc14679b5ae8 net: Add FIB table id to rtable Add the FIB table id to rtable to make the information available for IPv4 as it is for IPv6.

Re: [linux-next] oops in ip_route_input_noref

On 9/16/15 7:59 AM, Richard Alpe wrote: Sorry about that kvm cmdline was a copy-paste error. Here's the right one using virtio. I was just about to respond to that as well... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to

Re: [linux-next] oops in ip_route_input_noref

On 9/16/15 7:53 AM, Richard Alpe wrote: I to get an Oops in ip_route_input_noref(). It happens occasionally during bootup. KVM environment using virtio driver. Let me know if you need any additional info or if you want me to try to bisect it. Starting network... ... [0.877040] BUG: unable

Re: [linux-next] oops in ip_route_input_noref

On 9/16/15 3:24 AM, Sergey Senozhatsky wrote: Hi, 4.3.0-rc1-next-20150916 oops after removal of rndis usb device Sergey: Can you send me the oops output? Thanks, David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to

Re: [linux-next] oops in ip_route_input_noref

On 9/16/15 5:50 AM, Richard Alpe wrote: On 2015-09-16 11:24, Sergey Senozhatsky wrote: Hi, 4.3.0-rc1-next-20150916 oops after removal of rndis usb device Hi Sergey: Is this with KVM or baremetal? -8<- thanks for the analysis addr2line -e vmlinux -i 0x8146c0b1

Re: [linux-next] oops in ip_route_input_noref

On 9/16/15 3:24 AM, Sergey Senozhatsky wrote: Hi, 4.3.0-rc1-next-20150916 oops after removal of rndis usb device Sergey: Can you send me the oops output? Thanks, David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to

Re: [linux-next] oops in ip_route_input_noref

On 9/16/15 7:53 AM, Richard Alpe wrote: I to get an Oops in ip_route_input_noref(). It happens occasionally during bootup. KVM environment using virtio driver. Let me know if you need any additional info or if you want me to try to bisect it. Starting network... ... [0.877040] BUG: unable

Re: [linux-next] oops in ip_route_input_noref

On 9/16/15 5:50 AM, Richard Alpe wrote: On 2015-09-16 11:24, Sergey Senozhatsky wrote: Hi, 4.3.0-rc1-next-20150916 oops after removal of rndis usb device Hi Sergey: Is this with KVM or baremetal? -8<- thanks for the analysis addr2line -e vmlinux -i 0x8146c0b1

Re: [linux-next] oops in ip_route_input_noref

On 9/16/15 7:59 AM, Richard Alpe wrote: Sorry about that kvm cmdline was a copy-paste error. Here's the right one using virtio. I was just about to respond to that as well... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to

Re: [linux-next] oops in ip_route_input_noref

On 9/16/15 9:00 AM, Fabio Estevam wrote: On Wed, Sep 16, 2015 at 6:24 AM, Sergey Senozhatsky wrote: added by b7503e0cdb5dbec5d201aa69dc14679b5ae8 net: Add FIB table id to rtable Add the FIB table id to rtable to make the information available

Re: [GIT] Networking

On 9/2/15 11:35 PM, David Miller wrote: Another merge window, another set of networking changes. I've heard rumblings that the lightweight tunnels infrastructure has been voted networking change of the year. But what do I know? ... 9) Add support for "light weight tunnels", which allow

Re: [GIT] Networking

On 9/2/15 11:35 PM, David Miller wrote: Another merge window, another set of networking changes. I've heard rumblings that the lightweight tunnels infrastructure has been voted networking change of the year. But what do I know? ... 9) Add support for "light weight tunnels", which allow

Re: [RFC/PATCH] perf sched: Implement 'perf sched runtime' command

On 8/25/15 1:07 AM, Namhyung Kim wrote: Hi David, On Mon, Aug 24, 2015 at 11:19:44PM -0700, David Ahern wrote: On 8/24/15 11:11 PM, Namhyung Kim wrote: +static int perf_sched__read_runtime_events(struct perf_sched *sched) +{ + const struct perf_evsel_str_handler handlers

Re: [RFC/PATCH] perf sched: Implement 'perf sched runtime' command

On 8/24/15 11:11 PM, Namhyung Kim wrote: +static int perf_sched__read_runtime_events(struct perf_sched *sched) +{ + const struct perf_evsel_str_handler handlers[] = { + { "sched:sched_switch", process_sched_switch_event, }, + {

Re: [RFC/PATCH] perf sched: Implement 'perf sched runtime' command

On 8/25/15 1:07 AM, Namhyung Kim wrote: Hi David, On Mon, Aug 24, 2015 at 11:19:44PM -0700, David Ahern wrote: On 8/24/15 11:11 PM, Namhyung Kim wrote: +static int perf_sched__read_runtime_events(struct perf_sched *sched) +{ + const struct perf_evsel_str_handler handlers

Re: [RFC/PATCH] perf sched: Implement 'perf sched runtime' command

On 8/24/15 11:11 PM, Namhyung Kim wrote: +static int perf_sched__read_runtime_events(struct perf_sched *sched) +{ + const struct perf_evsel_str_handler handlers[] = { + { sched:sched_switch, process_sched_switch_event, }, + {

Re: [PATCH 12/24] task_diag: add a new group to get tasks memory mappings (v2)

On 7/14/15 2:08 PM, Oleg Nesterov wrote: On 07/06, Andrey Vagin wrote: +static int task_vma_num(struct mm_struct *mm) +{ + struct vm_area_struct *vma; + int n_vma = 0; + + if (!mm || !atomic_inc_not_zero(>mm_users)) + return 0; + + down_read(>mmap_sem); +

Re: [PATCH 20/24] task_diag: Only add VMAs for thread_group leader

On 7/14/15 1:47 PM, Oleg Nesterov wrote: On 07/06, Andrey Vagin wrote: From: David Ahern threads of a process share the same VMAs, so when dumping all threads for all processes only push vma data for group leader. ... @@ -492,6 +493,13 @@ static int task_diag_fill(struct task_struct *tsk

Re: [PATCH 20/24] task_diag: Only add VMAs for thread_group leader

On 7/14/15 1:47 PM, Oleg Nesterov wrote: On 07/06, Andrey Vagin wrote: From: David Ahern dsah...@gmail.com threads of a process share the same VMAs, so when dumping all threads for all processes only push vma data for group leader. ... @@ -492,6 +493,13 @@ static int task_diag_fill(struct

Re: [PATCH 12/24] task_diag: add a new group to get tasks memory mappings (v2)

On 7/14/15 2:08 PM, Oleg Nesterov wrote: On 07/06, Andrey Vagin wrote: +static int task_vma_num(struct mm_struct *mm) +{ + struct vm_area_struct *vma; + int n_vma = 0; + + if (!mm || !atomic_inc_not_zero(mm-mm_users)) + return 0; + +

Re: [PATCH 0/24] kernel: add a netlink interface to get information about processes (v2)

On 7/7/15 10:27 AM, Andy Lutomirski wrote: On Tue, Jul 7, 2015 at 9:25 AM, Arnaldo Carvalho de Melo wrote: Em Tue, Jul 07, 2015 at 06:43:46PM +0300, Andrew Vagin escreveu: On Mon, Jul 06, 2015 at 10:10:32AM -0700, Andy Lutomirski wrote: On Mon, Jul 6, 2015 at 1:47 AM, Andrey Vagin wrote:

Re: [PATCH 0/24] kernel: add a netlink interface to get information about processes (v2)

On 7/7/15 10:24 AM, Andy Lutomirski wrote: On Tue, Jul 7, 2015 at 9:17 AM, David Ahern wrote: On 7/7/15 9:56 AM, Andy Lutomirski wrote: Netlink is fine for these use cases (if they were related to the netns, not the pid ns or user ns), and it works. It's still tedious -- I bet that if you

Re: [PATCH 0/24] kernel: add a netlink interface to get information about processes (v2)

On 7/7/15 9:56 AM, Andy Lutomirski wrote: Netlink is fine for these use cases (if they were related to the netns, not the pid ns or user ns), and it works. It's still tedious -- I bet that if you used a syscall, the user code would be considerable shorter, though. :) How would this be a

Re: [PATCH 0/24] kernel: add a netlink interface to get information about processes (v2)

On 7/7/15 9:56 AM, Andy Lutomirski wrote: Netlink is fine for these use cases (if they were related to the netns, not the pid ns or user ns), and it works. It's still tedious -- I bet that if you used a syscall, the user code would be considerable shorter, though. :) How would this be a

Re: [PATCH 0/24] kernel: add a netlink interface to get information about processes (v2)

On 7/7/15 10:24 AM, Andy Lutomirski wrote: On Tue, Jul 7, 2015 at 9:17 AM, David Ahern dsah...@gmail.com wrote: On 7/7/15 9:56 AM, Andy Lutomirski wrote: Netlink is fine for these use cases (if they were related to the netns, not the pid ns or user ns), and it works. It's still tedious -- I

Re: [PATCH 0/24] kernel: add a netlink interface to get information about processes (v2)

On 7/7/15 10:27 AM, Andy Lutomirski wrote: On Tue, Jul 7, 2015 at 9:25 AM, Arnaldo Carvalho de Melo a...@kernel.org wrote: Em Tue, Jul 07, 2015 at 06:43:46PM +0300, Andrew Vagin escreveu: On Mon, Jul 06, 2015 at 10:10:32AM -0700, Andy Lutomirski wrote: On Mon, Jul 6, 2015 at 1:47 AM, Andrey

Re: [PATCH] perf record: Let user have timestamps with per-thread recording

On 7/6/15 5:51 AM, Adrian Hunter wrote: diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c index 6be3c01ff6f8..ec98e5b4e14e 100644 --- a/tools/perf/util/evsel.c +++ b/tools/perf/util/evsel.c @@ -707,7 +707,8 @@ void perf_evsel__config(struct perf_evsel *evsel, struct record_opts

Re: [PATCH] perf record: Let user have timestamps with per-thread recording

On 7/6/15 5:51 AM, Adrian Hunter wrote: diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c index 6be3c01ff6f8..ec98e5b4e14e 100644 --- a/tools/perf/util/evsel.c +++ b/tools/perf/util/evsel.c @@ -707,7 +707,8 @@ void perf_evsel__config(struct perf_evsel *evsel, struct record_opts

Re: [PATCH regression 4.0 -> 4.1] tools perf: Fix build breakage if prefix= is specified

On 6/18/15 2:39 PM, Lukas Wunner wrote: So the prefix parameter should have no effect at all in your case, no matter to what you set it. It does: rpmbuild -bb --define="_prefix /tmp/junk" SPECS/perf.spec ... + make -s -C tools/perf V=1 WERROR=0 NO_LIBUNWIND=1 HAVE_CPLUS_DEMANGLE=1 NO_GTK2=1

Re: [PATCH regression 4.0 -> 4.1] tools perf: Fix build breakage if prefix= is specified

On 6/18/15 1:59 PM, Lukas Wunner wrote: E.g. the Debian "linux-tools" package makes use of that feature: MAKE_PERF := $(MAKE) prefix=/usr V=1 ARCH=$(KERNEL_ARCH_PERF) EXTRA_WARNINGS=-Wno-error Source:

Re: [PATCH regression 4.0 - 4.1] tools perf: Fix build breakage if prefix= is specified

On 6/18/15 1:59 PM, Lukas Wunner wrote: E.g. the Debian linux-tools package makes use of that feature: MAKE_PERF := $(MAKE) prefix=/usr V=1 ARCH=$(KERNEL_ARCH_PERF) EXTRA_WARNINGS=-Wno-error Source:

Re: [PATCH regression 4.0 - 4.1] tools perf: Fix build breakage if prefix= is specified

On 6/18/15 2:39 PM, Lukas Wunner wrote: So the prefix parameter should have no effect at all in your case, no matter to what you set it. It does: rpmbuild -bb --define=_prefix /tmp/junk SPECS/perf.spec ... + make -s -C tools/perf V=1 WERROR=0 NO_LIBUNWIND=1 HAVE_CPLUS_DEMANGLE=1 NO_GTK2=1

Re: [PATCH V3 1/2] perf,tools: add time out to force stop proc map processing

On 6/17/15 1:56 AM, kan.li...@intel.com wrote: diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c index 793b150..ac6cf2a 100644 --- a/tools/perf/util/event.c +++ b/tools/perf/util/event.c @@ -213,6 +213,8 @@ static int perf_event__synthesize_fork(struct perf_tool *tool,

Re: [PATCH V3 1/2] perf,tools: add time out to force stop proc map processing

On 6/17/15 1:56 AM, kan.li...@intel.com wrote: diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c index 793b150..ac6cf2a 100644 --- a/tools/perf/util/event.c +++ b/tools/perf/util/event.c @@ -213,6 +213,8 @@ static int perf_event__synthesize_fork(struct perf_tool *tool,

Re: [RFC PATCH] perf/kvm: Guest Symbol Resolution for powerpc

On 6/16/15 7:24 PM, Hemant Kumar wrote: Because, this depends on the kernel tracepoint "kvm_hv:kvm_guest_exit". perf_prepare_sample() in the kernel side sets the event->header.misc field to PERF_RECORD_MISC_KERNEL through perf_misc_flags(pt_regs). In case of tracepoints which always get hit in

Re: [PATCH 1/1] perf,tools: add time out to force stop endless mmap processing

On 6/16/15 9:11 AM, Arnaldo Carvalho de Melo wrote: Then, that being said, having a sane upper limit on the time for processing those events makes the tool more robust and allows it to do most of its work, just samples for the maps not synthesized will fail to get resolved to symbols/DSOs. If

Re: [RFC PATCH] perf/kvm: Guest Symbol Resolution for powerpc

On 6/15/15 8:50 PM, Hemant Kumar wrote: +/* + * Get the instruction pointer from the tracepoint data + */ +u64 arch__get_ip(struct perf_evsel *evsel, struct perf_sample *data) +{ + u64 tp_ip = data->ip; + int trap; + + if (!strcmp(KVMPPC_EXIT, evsel->name)) { +

Re: [RFC PATCH] perf/kvm: Guest Symbol Resolution for powerpc

On 6/15/15 8:50 PM, Hemant Kumar wrote: +/* + * Get the instruction pointer from the tracepoint data + */ +u64 arch__get_ip(struct perf_evsel *evsel, struct perf_sample *data) +{ + u64 tp_ip = data-ip; + int trap; + + if (!strcmp(KVMPPC_EXIT, evsel-name)) { + trap

Re: [PATCH 1/1] perf,tools: add time out to force stop endless mmap processing

On 6/16/15 9:11 AM, Arnaldo Carvalho de Melo wrote: Then, that being said, having a sane upper limit on the time for processing those events makes the tool more robust and allows it to do most of its work, just samples for the maps not synthesized will fail to get resolved to symbols/DSOs. If

Re: [RFC PATCH] perf/kvm: Guest Symbol Resolution for powerpc

On 6/16/15 7:24 PM, Hemant Kumar wrote: Because, this depends on the kernel tracepoint kvm_hv:kvm_guest_exit. perf_prepare_sample() in the kernel side sets the event-header.misc field to PERF_RECORD_MISC_KERNEL through perf_misc_flags(pt_regs). In case of tracepoints which always get hit in the

Re: [PATCH 1/1] perf,tools: add time out to force stop endless mmap processing

coming back to this ... On 6/12/15 2:39 PM, Liang, Kan wrote: Yes, perf always can read proc file. The problem is that the proc file is huge and keep growing faster than proc reader. So perf top do loop in perf_event__synthesize_mmap_events until the test case exit. I'm confused. How are you

Re: [PATCH 1/1] perf,tools: add time out to force stop endless mmap processing

On 6/12/15 4:41 PM, Liang, Kan wrote: On 6/12/15 2:39 PM, Liang, Kan wrote: Here are the test results. Please note that I get "synthesized threads took..." after the test case exit. It means both way have the same issue. Got it. So what you really mean is launching perf on an already

Re: [PATCH 1/1] perf,tools: add time out to force stop endless mmap processing

On 6/12/15 2:39 PM, Liang, Kan wrote: Here are the test results. Please note that I get "synthesized threads took..." after the test case exit. It means both way have the same issue. Got it. So what you really mean is launching perf on an already running process perf never finishes

Re: [PATCH 1/1] perf,tools: add time out to force stop endless mmap processing

On 6/12/15 12:19 PM, Liang, Kan wrote: [perf]$ sudo ./perf record -e instructions:pp --pid 14560 Reading /proc/14560/maps cost 13.12690599 s ^C[ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.108 MB perf.data (2783 samples) ] so perf was able to read the proc

Re: [PATCH 1/1] perf,tools: add time out to force stop endless mmap processing

On 6/12/15 11:05 AM, Liang, Kan wrote: On 6/12/15 8:42 AM, Liang, Kan wrote: On 6/11/15 12:47 PM, Andi Kleen wrote: Can you elaborate on an example? I don't see how this can happen reading a maps file. And it does not read maps for all threads only thread group leaders. This is with a

Re: [PATCH 1/1] perf,tools: add time out to force stop endless mmap processing

On 6/12/15 8:42 AM, Liang, Kan wrote: On 6/11/15 12:47 PM, Andi Kleen wrote: Can you elaborate on an example? I don't see how this can happen reading a maps file. And it does not read maps for all threads only thread group leaders. This is with a stress test case that generates lots of

Re: [RFC PATCH] perf: Add PERF_RECORD_SWITCH to indicate context switches

On 6/12/15 7:28 AM, Pawel Moll wrote: Thanks, that's clear then. There will just need to be a flag to indicate whether it is scheduling in or out. Just a thought: wouldn't it be good to know what CPU have we been scheduled from/to? This kind of information would be especially valuable in

Re: [RFC PATCH] perf: Add PERF_RECORD_SWITCH to indicate context switches

On 6/12/15 5:12 AM, Adrian Hunter wrote: This new PERF_RECORD_SWITCH event does not have those problems and it also has a couple of other small advantages. It is easier to use because it is an auxiliary event (like mmap, comm and task events) which can be enabled by setting a single bit. It is

Re: [RFC PATCH] perf: Add PERF_RECORD_SWITCH to indicate context switches

On 6/12/15 4:34 AM, Adrian Hunter wrote: On 12/06/15 03:47, David Ahern wrote: On 6/11/15 8:15 AM, Peter Zijlstra wrote: This new PERF_RECORD_SWITCH event does not have those problems and it also has a couple of other small advantages. It is easier to use because it is an auxiliary event (like

[tip:perf/core] perf tools: Update MANIFEST per files removed from kernel

Commit-ID: c8ad7063626406181a7ebab10cb31b4f741b13d4 Gitweb: http://git.kernel.org/tip/c8ad7063626406181a7ebab10cb31b4f741b13d4 Author: David Ahern AuthorDate: Fri, 5 Jun 2015 13:42:53 -0400 Committer: Arnaldo Carvalho de Melo CommitDate: Thu, 11 Jun 2015 22:54:23 -0300 perf tools

[tip:perf/core] perf tools: Update MANIFEST per files removed from kernel

Commit-ID: c8ad7063626406181a7ebab10cb31b4f741b13d4 Gitweb: http://git.kernel.org/tip/c8ad7063626406181a7ebab10cb31b4f741b13d4 Author: David Ahern david.ah...@oracle.com AuthorDate: Fri, 5 Jun 2015 13:42:53 -0400 Committer: Arnaldo Carvalho de Melo a...@redhat.com CommitDate: Thu, 11 Jun

Re: [PATCH 1/1] perf,tools: add time out to force stop endless mmap processing

On 6/12/15 12:19 PM, Liang, Kan wrote: [perf]$ sudo ./perf record -e instructions:pp --pid 14560 Reading /proc/14560/maps cost 13.12690599 s ^C[ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.108 MB perf.data (2783 samples) ] so perf was able to read the proc

Re: [PATCH 1/1] perf,tools: add time out to force stop endless mmap processing

On 6/12/15 2:39 PM, Liang, Kan wrote: Here are the test results. Please note that I get synthesized threads took... after the test case exit. It means both way have the same issue. Got it. So what you really mean is launching perf on an already running process perf never finishes

Re: [PATCH 1/1] perf,tools: add time out to force stop endless mmap processing

On 6/12/15 4:41 PM, Liang, Kan wrote: On 6/12/15 2:39 PM, Liang, Kan wrote: Here are the test results. Please note that I get synthesized threads took... after the test case exit. It means both way have the same issue. Got it. So what you really mean is launching perf on an already running

Re: [PATCH 1/1] perf,tools: add time out to force stop endless mmap processing

coming back to this ... On 6/12/15 2:39 PM, Liang, Kan wrote: Yes, perf always can read proc file. The problem is that the proc file is huge and keep growing faster than proc reader. So perf top do loop in perf_event__synthesize_mmap_events until the test case exit. I'm confused. How are you

Re: [RFC PATCH] perf: Add PERF_RECORD_SWITCH to indicate context switches

On 6/12/15 7:28 AM, Pawel Moll wrote: Thanks, that's clear then. There will just need to be a flag to indicate whether it is scheduling in or out. Just a thought: wouldn't it be good to know what CPU have we been scheduled from/to? This kind of information would be especially valuable in

Re: [PATCH 1/1] perf,tools: add time out to force stop endless mmap processing

On 6/12/15 8:42 AM, Liang, Kan wrote: On 6/11/15 12:47 PM, Andi Kleen wrote: Can you elaborate on an example? I don't see how this can happen reading a maps file. And it does not read maps for all threads only thread group leaders. This is with a stress test case that generates lots of

Re: [PATCH 1/1] perf,tools: add time out to force stop endless mmap processing

On 6/12/15 11:05 AM, Liang, Kan wrote: On 6/12/15 8:42 AM, Liang, Kan wrote: On 6/11/15 12:47 PM, Andi Kleen wrote: Can you elaborate on an example? I don't see how this can happen reading a maps file. And it does not read maps for all threads only thread group leaders. This is with a

Re: [RFC PATCH] perf: Add PERF_RECORD_SWITCH to indicate context switches

On 6/12/15 4:34 AM, Adrian Hunter wrote: On 12/06/15 03:47, David Ahern wrote: On 6/11/15 8:15 AM, Peter Zijlstra wrote: This new PERF_RECORD_SWITCH event does not have those problems and it also has a couple of other small advantages. It is easier to use because it is an auxiliary event (like

<    3   4   5   6   7   8   9   10   11   12   >