cheduled in.
> - *
> - * we cannot simply called update_context_time()
> - * because of locking issue as we can be called in
> - * NMI context
> - */
> - calc_timer_values(event, &now, &enabled, &running);
> -
> - userpg = rb->u
, thereby making it
> suitable for use with mediated vPMU.
So IBS cannot be used in the guest (with MEDIATED_VPMU) and host can
profile guests with it, right?
Thanks,
Namhyung
>
> Signed-off-by: Sandipan Das
> Signed-off-by: Mingwei Zhang
> ---
> arch/x86/events/amd/core.c | 2
gt;
> Add a dedicated list to track all the pmus with the PASSTHROUGH cap, which
s/PASSTHROUGH/MEDIATED_VPMU/ ?
Thanks,
Namhyung
> may require switching the guest context. It can avoid going through the
> huge pmus list.
>
> Suggested-by: Peter Zijlstra (Intel)
> Signed-off-by: Kan Liang
> Signed-off-by: Mingwei Zhang
perf_ctx_disable(&cpuctx->ctx, EVENT_GUEST);
if (cpuctx->task_ctx)
perf_ctx_disable(cpuctx->task_ctx, EVENT_GUEST);
ctx_sched_out(&cpuctx->ctx, NULL, EVENT_GUEST);
if (cpuctx->task_ctx)
task_ctx_sched_out(cpuctx->ta
On Tue, May 20, 2025 at 12:09:02PM -0400, Liang, Kan wrote:
>
>
> On 2025-05-19 2:58 a.m., Namhyung Kim wrote:
> > Hello,
> >
> > On Mon, Mar 24, 2025 at 05:30:44PM +, Mingwei Zhang wrote:
> >> From: Kan Liang
> >>
> >> Current perf do
5c1 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -163,7 +163,8 @@ enum event_type_t {
> /* see ctx_resched() for details */
> EVENT_CPU = 0x10,
> EVENT_CGROUP= 0x20,
> - EVENT_FLAGS = EVENT_CGROUP,
> + EVENT_GUEST = 0x
1/3 PASSED, 0 SKIPPED, 0 FAILED
>
> Fixes: a496d0cdc84d ("selftests/bpf: Add a test for kmem_cache_iter")
> Signed-off-by: T.J. Mercier
Oops, thanks for fixing this.
Acked-by: Namhyung Kim
Thanks,
Namhyung
> ---
> tools/testing/selftests/bpf/prog_tests/kmem_cache_iter
Pavlu
Cc: Sami Tolvanen
Cc: Daniel Gomez
Cc: linux-modu...@vger.kernel.org
Signed-off-by: Namhyung Kim
---
tools/perf/util/machine.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index 27d5345d2b307a97..8bb34689e3ceeec4 100644
--- a/
Hello,
On Fri, Jul 12, 2024 at 12:45 PM Guilherme Amadio wrote:
>
> Hi Namhyung, Arnaldo,
>
> Here is version 3 of the patchset. I see the change to send output to devnull
> has already been applied, so I am submitting the remaining work only.
>
> The difference with previo
On Wed, Jul 3, 2024 at 4:05 PM Steven Rostedt wrote:
>
> On Wed, 3 Jul 2024 14:33:21 -0700
> Namhyung Kim wrote:
>
> > On Wed, Jul 03, 2024 at 03:36:17PM -0400, Steven Rostedt wrote:
> > > On Tue, 2 Jul 2024 16:40:46 -0700
> > > Namhyung Kim wrote:
> >
On Wed, Jul 03, 2024 at 03:36:17PM -0400, Steven Rostedt wrote:
> On Tue, 2 Jul 2024 16:40:46 -0700
> Namhyung Kim wrote:
>
> > +CC Steve and linux-trace-kernel list.
>
> There doesn't seem to be a cover page, and it doesn't apply on
> v6.10-rc6 nor on tip.
+CC Steve and linux-trace-kernel list.
Thanks,
Namhyung
On Fri, Jun 28, 2024 at 10:34:29PM +0200, Guilherme Amadio wrote:
> Other tools, in tools/verification and tools/tracing, make use of
> libtraceevent and libtracefs as dependencies. This allows setting
> up the feature check flags
this already possible via some other means? It'd be great to be able
> to do this directly at the perf_event sample via the ABI or a probe.
I don't think the current perf ABI allows capturing %fs/%gs + offset.
IIRC kprobes/uprobes don't have that too but I could be wrong.
Thanks,
S' and defines macro 'HAVE_PERF_REGS_SUPPORT' for statically
> compiling the tool.
>
> [...]
Applied to perf-tools-next, thanks!
Best regards,
--
Namhyung Kim
"Michael S. Tsirkin"
Cc: Jason Wang
Cc: k...@vger.kernel.org
Cc: virtualizat...@lists.linux.dev
Cc: net...@vger.kernel.org
Signed-off-by: Namhyung Kim
---
tools/include/uapi/linux/vhost.h | 8
1 file changed, 8 insertions(+)
diff --git a/tools/include/uapi/linux/vhost.h b/too
Hi Peter,
On Tue, Apr 20, 2021 at 7:28 PM Peter Zijlstra wrote:
>
> On Fri, Apr 16, 2021 at 06:49:09PM +0900, Namhyung Kim wrote:
> > On Thu, Apr 15, 2021 at 11:51 PM Peter Zijlstra
> > wrote:
> > > > +static void perf_update_cgroup_node(struct perf_event *event
Hi Arnaldo,
Could you please pick this up? The kernel part is landed in the
tip.git already.
Thanks,
Namhyung
On Wed, Feb 10, 2021 at 5:33 PM Namhyung Kim wrote:
>
> It counts how often cgroups are changed actually during the context
> switches.
>
> # perf stat -a -e context-
if (!evsel__bpf_counter_events)
> + return false;
> +
> + ptr = strstr(evsel__bpf_counter_events, name);
> + name_len = strlen(name);
> +
> + /* check name matches a full token in evsel__bpf_counter_events */
> + match = (ptr
The following commit has been merged into the perf/core branch of tip:
Commit-ID: d0d1dd628527c77db2391ce0293c1ed344b2365f
Gitweb:
https://git.kernel.org/tip/d0d1dd628527c77db2391ce0293c1ed344b2365f
Author:Namhyung Kim
AuthorDate:Wed, 10 Feb 2021 17:33:26 +09:00
Committer
The following commit has been merged into the perf/core branch of tip:
Commit-ID: 7c8056bb366b1b2dc8e4a3cc0b876e15a8ebca2c
Gitweb:
https://git.kernel.org/tip/7c8056bb366b1b2dc8e4a3cc0b876e15a8ebca2c
Author:Namhyung Kim
AuthorDate:Wed, 10 Feb 2021 17:33:25 +09:00
Committer
The following commit has been merged into the perf/core branch of tip:
Commit-ID: 64f6aeb6dc7a2426278fd9017264cf24bfdbebd6
Gitweb:
https://git.kernel.org/tip/64f6aeb6dc7a2426278fd9017264cf24bfdbebd6
Author:Namhyung Kim
AuthorDate:Wed, 10 Feb 2021 17:33:25 +09:00
Committer
The following commit has been merged into the perf/core branch of tip:
Commit-ID: a389ea9c161d142bf11fd4c553988c2daa9f5404
Gitweb:
https://git.kernel.org/tip/a389ea9c161d142bf11fd4c553988c2daa9f5404
Author:Namhyung Kim
AuthorDate:Wed, 10 Feb 2021 17:33:26 +09:00
Committer
On Fri, Apr 16, 2021 at 8:59 PM Peter Zijlstra wrote:
>
> On Fri, Apr 16, 2021 at 08:22:38PM +0900, Namhyung Kim wrote:
> > On Fri, Apr 16, 2021 at 7:28 PM Peter Zijlstra wrote:
> > >
> > > On Fri, Apr 16, 2021 at 11:29:30AM +0200, Peter Zijlstra wrote:
> &
#x27;t think we can use file offset since it's taken for auxtrace.
Maybe we can simply disallow that..
>
> This gets rid of the nasty variadic nature of the
> 'get-me-these-n-cgroups'. While still getting rid of the n*m fd issue
> you're facing.
As I said, it's not just a file descriptor problem. In fact, performance
is more concerning.
Thanks,
Namhyung
On Fri, Apr 16, 2021 at 6:29 PM Peter Zijlstra wrote:
>
>
> Duh.. this is a half-finished email I meant to save for later. Anyway,
> I'll reply more.
Nevermind, and thanks for your time! :-)
Namhyung
On Fri, Apr 16, 2021 at 6:27 PM Peter Zijlstra wrote:
>
> On Fri, Apr 16, 2021 at 08:48:12AM +0900, Namhyung Kim wrote:
> > On Thu, Apr 15, 2021 at 11:51 PM Peter Zijlstra
> > wrote:
> > > On Tue, Apr 13, 2021 at 08:53:36AM -0700, Namhyung Kim wrote:
>
> >
ould be deleted when the file descriptor of the
> > perf_event is closed.
> >
> > Cc: Tejun Heo
> > Reported-by: kernel test robot
>
> What, the whole thing?
Oh, it's just for build issues when !CONFIG_CGROUP_PERF
>
> > Acked-by: Song Liu
> >
Hi Peter,
Thanks for your review!
On Thu, Apr 15, 2021 at 11:51 PM Peter Zijlstra wrote:
>
> On Tue, Apr 13, 2021 at 08:53:36AM -0700, Namhyung Kim wrote:
> > As we can run many jobs (in container) on a big machine, we want to
> > measure each job's performance during th
Arnaldo Carvalho de Melo
> Cc: Mark Rutland
> Cc: Alexander Shishkin
> Cc: Jiri Olsa
> Cc: Namhyung Kim
> Signed-off-by: Rob Herring
> ---
> tools/lib/perf/include/internal/xyarray.h | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git
On Thu, Apr 15, 2021 at 3:23 AM Arnaldo Carvalho de Melo
wrote:
>
> Em Wed, Apr 14, 2021 at 03:02:08PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Thu, Apr 15, 2021 at 01:41:35AM +0900, Namhyung Kim escreveu:
> > > Hello,
> > >
> > > On Thu, Apr
On Thu, Apr 15, 2021 at 1:53 AM Rob Herring wrote:
>
> On Wed, Apr 14, 2021 at 11:41 AM Namhyung Kim wrote:
> >
> > Hello,
> >
> > On Thu, Apr 15, 2021 at 1:07 AM Rob Herring wrote:
> > > +void *perf_evsel__mmap_base(struct perf_e
the cpu and the thread is in
a valid range. Currently xyarray__entry() simply accesses
the content without checking the boundaries.
Thanks,
Namhyung
> +
> + return MMAP(evsel, cpu, thread)->base;
> +}
> +
> int perf_evsel__read_size(struct perf_evsel *evsel)
>
ty, X86_PMC_IDX_MAX))
> + return;
Maybe you can check it after clearing assigned counters.
Thanks,
Namhyung
> +
> +/* Don't need to clear the assigned counter. */
> + for (i = 0; i < cpuc->n_events; i++)
> + __clear_bit(cpuc->assi
Hi Arnaldo,
On Wed, Apr 14, 2021 at 9:23 PM Arnaldo Carvalho de Melo
wrote:
>
> Em Mon, Apr 12, 2021 at 03:22:29PM +0800, Yang Jihong escreveu:
> > On 2021/3/31 10:18, Yang Jihong wrote:
> > > On 2021/3/30 15:26, Namhyung Kim wrote:
> > > > On Sat, Mar
This enables reading event group's counter values together with a
PERF_EVENT_IOC_READ_CGROUP command like we do in the regular read().
Users should give a correct size of buffer to be read which includes
the total buffer size and the cgroup id.
Acked-by: Song Liu
Signed-off-by: Namhyun
o 5.8 usec.
Thanks,
Namhyung
Namhyung Kim (2):
perf/core: Share an event with multiple cgroups
perf/core: Support reading group events with shared cgroups
include/linux/perf_event.h | 22 ++
include/uapi/linux/perf_event.h | 2 +
kernel/events/core.c
ed-by: Song Liu
Signed-off-by: Namhyung Kim
---
include/linux/perf_event.h | 22 ++
include/uapi/linux/perf_event.h | 2 +
kernel/events/core.c| 480 ++--
3 files changed, 477 insertions(+), 27 deletions(-)
diff --git a/include/linux/perf_event.h
This enables reading event group's counter values together with a
PERF_EVENT_IOC_READ_CGROUP command like we do in the regular read().
Users should give a correct size of buffer to be read which includes
the total buffer size and the cgroup id.
Acked-by: Song Liu
Signed-off-by: Namhyun
hange the HW PMU).
It keeps the counters in a hash table with cgroup id as a key.
With this change, average processing time of my internal test workload
which runs tasks in a different cgroup and communicates by pipes
dropped from 11.3 usec to 5.8 usec.
Thanks,
Namhyung
Namhyung Kim (2):
perf
value and timings.
This attaches all cgroups in a single syscall and I didn't add the
DETACH command deliberately to make the implementation simple. The
attached cgroup nodes would be deleted when the file descriptor of the
perf_event is closed.
Cc: Tejun Heo
Acked-by: Song Liu
Signed-off-b
are based on prototypes [1], [2].
>
> [1] git clone https://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
> -b perf/record_threads
> [2] https://lore.kernel.org/lkml/20180913125450.21342-1-jo...@kernel.org/
>
> Suggested-by: Jiri Olsa
> Suggested-by: Namhyun
sages, but I think it's rare to
have both options and it'd be better changing them.
Suggested-by: Alexey Alexandrov
Signed-off-by: Namhyung Kim
---
tools/perf/util/record.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/record.c b/tools/perf/util
Hello,
On Thu, Apr 1, 2021 at 3:25 PM Wan Jiabing wrote:
>
> struct target is declared twice. One has been declared
> at 21st line. Remove the duplicate.
>
> Signed-off-by: Wan Jiabing
Acked-by: Namhyung Kim
I think we can move all the forward declarations to the top
(and sor
On Tue, Mar 30, 2021 at 3:33 PM Song Liu wrote:
> > On Mar 29, 2021, at 4:33 AM, Namhyung Kim wrote:
> >
> > On Mon, Mar 29, 2021 at 2:17 AM Song Liu wrote:
> >>> On Mar 23, 2021, at 9:21 AM, Namhyung Kim wrote:
> >>>
> >>> As we can run
Hello,
On Wed, Mar 24, 2021 at 11:30 PM Alexander Antonov
wrote:
>
> The previous version can be found at:
> v4:
> https://lkml.kernel.org/r/20210203135830.38568-1-alexander.anto...@linux.intel.com/
> Changes in this revision are:
> v4 -> v5:
> - Addressed comments
;s related to sort keys. The code works with a single
hist_entry for each event and symbol. But the default sort key
creates multiple entries for different threads and it causes the
confusion.
Thanks,
Namhyung
On Mon, Mar 29, 2021 at 2:32 AM Song Liu wrote:
> > On Mar 23, 2021, at 9:21 AM, Namhyung Kim wrote:
> >
> > This enables reading event group's counter values together with a
> > PERF_EVENT_IOC_READ_CGROUP command like we do in the regular read().
> > Users s
On Mon, Mar 29, 2021 at 2:17 AM Song Liu wrote:
> > On Mar 23, 2021, at 9:21 AM, Namhyung Kim wrote:
> >
> > As we can run many jobs (in container) on a big machine, we want to
> > measure each job's performance during the run. To do that, the
> > perf_eve
er to "dso,symbol" to avoid duplicate output when different
> > processes correspond to the same symbol.
> >
> > Signed-off-by: Yang Jihong
Acked-by: Namhyung Kim
Thanks,
Namhyung
> > ---
> >
> > Changes since v6:
> >- Remove separate setup
Hi Song,
Thanks for your review!
On Thu, Mar 25, 2021 at 9:56 AM Song Liu wrote:
> > On Mar 23, 2021, at 9:21 AM, Namhyung Kim wrote:
> >
> > As we can run many jobs (in container) on a big machine, we want to
> > measure each job's performance during the run. T
On Wed, Mar 24, 2021 at 12:47 PM Like Xu wrote:
>
> Hi Namhyung,
>
> On 2021/3/24 9:32, Namhyung Kim wrote:
> > Hello,
> >
> > On Mon, Mar 22, 2021 at 3:14 PM Like Xu wrote:
> >> +void reserve_lbr_buffers(struct perf_event *event)
> >> +{
> >
signal 12 sent to session 'test [11596]'
> signal 12 sent to session 'test [11596]'
> test daemon ping
> test daemon lock
> test child finished with 0
> end
> daemon operations: Ok
>
> [1] https://bugs.launchpad.net/ubuntu/+source/da
cpuc->lbr_xsave = kmem_cache_alloc(kmem_cache,
> GFP_KERNEL);
> + }
> +}
I think we should use kmem_cache_alloc_node().
Thanks,
Namhyung
Hi Song,
On Wed, Mar 24, 2021 at 9:30 AM Song Liu wrote:
>
>
>
> > On Mar 23, 2021, at 9:21 AM, Namhyung Kim wrote:
> >
> > As we can run many jobs (in container) on a big machine, we want to
> > measure each job's performance during the run. To do that, t
value and timings.
This attaches all cgroups in a single syscall and I didn't add the
DETACH command deliberately to make the implementation simple. The
attached cgroup nodes would be deleted when the file descriptor of the
perf_event is closed.
Cc: Tejun Heo
Signed-off-by: Namhyung Kim
---
This enables reading event group's counter values together with a
PERF_EVENT_IOC_READ_CGROUP command like we do in the regular read().
Users should give a correct size of buffer to be read.
Signed-off-by: Namhyung Kim
---
kernel/events/core.c | 119 +
in a different cgroup and communicates by pipes
dropped from 11.3 usec to 5.8 usec.
Thanks,
Namhyung
Namhyung Kim (2):
perf/core: Share an event with multiple cgroups
perf/core: Support reading group events with shared cgroups
include/linux/perf_event.h | 22 ++
include/uapi/linux/perf_ev
Hi Arnaldo,
On Sat, Mar 20, 2021 at 12:35 AM Arnaldo Carvalho de Melo
wrote:
>
> Em Fri, Mar 19, 2021 at 09:54:59AM +0900, Namhyung Kim escreveu:
> > On Fri, Mar 19, 2021 at 9:22 AM Song Liu wrote:
> > > > On Mar 18, 2021, at 5:09 PM, Arnaldo wrote:
> > > >
enum uncore_access_type access_type;
> + u64 box_ctrl; /* Unit ctrl addr of the first box */
> + u64 *box_ctrl_die; /* Unit ctrl addr of the first box of
> each die */
> + u16 type; /* Type ID of the uncore block
> idle
>464,172,105 instructions #0.24 insn per cycle
> #6.07 stalled cycles
> per insn
> 91,567,662 branches # 11.438 M/sec
> 7,756,054 branch-misses
t;>>
> >>>
> >>>> On Mar 17, 2021, at 6:11 AM, Arnaldo Carvalho de Melo
> >> wrote:
> >>>>
> >>>> Em Wed, Mar 17, 2021 at 02:29:28PM +0900, Namhyung Kim escreveu:
> >>>>> Hi Song,
> >>&g
On Thu, Mar 18, 2021 at 4:22 PM Song Liu wrote:
>
>
>
> > On Mar 17, 2021, at 10:54 PM, Namhyung Kim wrote:
> >
>
> [...]
>
> >> +
> >> +static int bperf_reload_leader_program(struct evsel *evsel, int
> >> attr_map_fd,
> >> +
*argv)
>
> setup_browser(true);
>
> + /*
> +* Events of different processes may correspond to the same
> +* symbol, we do not care about the processes in annotate,
> +* set sort order to avoid repeated output.
> +*/
>
+
> +base_cycles=$(perf stat --no-big-num -e cycles -- stressapptest -s 3 -M 100
> -m 1 2>&1 | grep -e cycles | awk '{print $1}')
> +bpf_cycles=$(perf stat --no-big-num --bpf-counters -e cycles --
> stressapptest -s 3 -M 100 -m 1 2>&1 | grep -e cycles | awk '{print $1}')
I think just awk '/cycles/ {print $1}' should work.
Thanks,
Namhyung
> +
> +compare_number $base_cycles $bpf_cycles
> +exit 0
> --
> 2.30.2
>
*skel = evsel->follower_skel;
> + __u32 num_cpu_bpf = cpu__max_cpu();
> + struct bpf_perf_event_value values[num_cpu_bpf];
> + int reading_map_fd, err = 0;
> + __u32 i, j, num_cpu;
> +
> + bperf_sync_counters(evsel);
> + read
On Thu, Mar 18, 2021 at 12:52 PM Song Liu wrote:
>
>
>
> > On Mar 17, 2021, at 6:11 AM, Arnaldo Carvalho de Melo
> > wrote:
> >
> > Em Wed, Mar 17, 2021 at 02:29:28PM +0900, Namhyung Kim escreveu:
> >> Hi Song,
> >>
> >> On Wed, Ma
When it failed to get section names, it should call
bpf_object__elf_finish() like others.
Signed-off-by: Namhyung Kim
---
tools/lib/bpf/libbpf.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 2f351d3ad3e7..8d610259f4be
The following commit has been merged into the perf/core branch of tip:
Commit-ID: 9483409ab5067941860754e78a4a44a60311d276
Gitweb:
https://git.kernel.org/tip/9483409ab5067941860754e78a4a44a60311d276
Author:Namhyung Kim
AuthorDate:Mon, 15 Mar 2021 12:34:36 +09:00
Committer
The following commit has been merged into the perf/core branch of tip:
Commit-ID: ff65338e78418e5970a7aabbabb94c46f2bb821d
Gitweb:
https://git.kernel.org/tip/ff65338e78418e5970a7aabbabb94c46f2bb821d
Author:Namhyung Kim
AuthorDate:Thu, 11 Mar 2021 20:54:13 +09:00
Committer
The following commit has been merged into the perf/core branch of tip:
Commit-ID: bdacfaf26da166dd56c62f23f27a4b3e71f2d89e
Gitweb:
https://git.kernel.org/tip/bdacfaf26da166dd56c62f23f27a4b3e71f2d89e
Author:Namhyung Kim
AuthorDate:Thu, 11 Mar 2021 20:54:12 +09:00
Committer
cupy multiple PMCs.
Right, it'd be really helpful when the PMCs are frequently or mostly shared.
But it'd also increase the overhead for uncontended cases as BPF programs
need to run on every context switch. Depending on the workload, it may
cause a non-negligible performance impact. So u
; record as well.
>
> Fixes: 01330d7288e0 ("perf/x86: Allow zero PEBS status with only single
> active event")
> Reported-by: Vince Weaver
> Suggested-by: Peter Zijlstra (Intel)
> Signed-off-by: Kan Liang
> Cc: sta...@vger.kernel.org
Tested-by: Namhyung Kim
Thanks,
On Tue, Mar 16, 2021 at 9:28 PM Liang, Kan wrote:
>
>
>
> On 3/16/2021 3:22 AM, Namhyung Kim wrote:
> > Hi Peter and Kan,
> >
> > On Thu, Mar 4, 2021 at 5:22 AM Peter Zijlstra wrote:
> >>
> >> On Wed, Mar 03, 2021 at 02:53:00PM -0500, Liang, Kan
day.
I got a similar issue on ivybridge machines which caused kernel crash.
My case it's related to the branch stack with PEBS events but I think
it's the same issue. And I can confirm that the above approach of
updating p->status fixed the problem.
I've talked to Stephane about this, and he wants to make it more
robust when we see stale (or invalid) PEBS records. I'll send the
patch soon.
Thanks,
Namhyung
On Mon, Mar 15, 2021 at 10:28 PM Jiri Olsa wrote:
>
> On Mon, Mar 15, 2021 at 01:56:41PM +0900, Namhyung Kim wrote:
> > I got several memory leak reports from Asan with a simple command. It
> > was because VDSO is not released due to the refcount. Like in
> > __dsos_ad
util/ordered-events.c:323
#10 0x559bce519bea in __perf_session__process_events util/session.c:2268
#11 0x559bce519bea in perf_session__process_events util/session.c:2297
#12 0x559bce2e7a52 in process_buildids
/home/namhyung/project/linux/tools/perf/builtin-record.c:1017
#13
I found the ring buffer pages are allocated in the node but the ring
buffer itself is not. Let's convert it to use kzalloc_node() too.
Signed-off-by: Namhyung Kim
---
kernel/events/ring_buffer.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/kernel/e
notate is output.
>
> Solution of this patch is to remove zfree in hists__find_annotations and
> change sort order to "dso,symbol" to avoid duplicate output when different
> processes correspond to the same symbol.
Looks good. But I'm not sure about the branch stack mode.
On Sat, Mar 13, 2021 at 12:38 AM Song Liu wrote:
>
>
>
> > On Mar 12, 2021, at 12:36 AM, Namhyung Kim wrote:
> >
> > Hi,
> >
> > On Fri, Mar 12, 2021 at 11:03 AM Song Liu wrote:
> >>
> >> perf uses performance monitoring counters (PMCs)
On Fri, Mar 12, 2021 at 4:19 PM Yang Jihong wrote:
>
>
> Hello,
> On 2021/3/12 13:49, Namhyung Kim wrote:
> > Hi,
> >
> > On Fri, Mar 12, 2021 at 12:24 PM Yang Jihong wrote:
> >>
> >> Hello, Namhyung
> >>
> >> On 2021/3/11 22:42,
f -e cycles -t 100,101
Hmm... so it loads both leader and follower programs if needed, right?
Does it support multiple followers with different targets at the same time?
Thanks,
Namhyung
Hi,
On Fri, Mar 12, 2021 at 12:24 PM Yang Jihong wrote:
>
> Hello, Namhyung
>
> On 2021/3/11 22:42, Namhyung Kim wrote:
> > Hi,
> >
> > On Thu, Mar 11, 2021 at 5:48 PM Yang Jihong wrote:
> >>
> >> Hello,
> >>
> >> On 2021/3/6
this solution is feasible, look forward to your review.
What about this? (not tested)
diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index a23ba6bb99b6..a91fe45bd69f 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -374,13 +374,6 @@ static void hists__find_annotations(struct hists *hists,
} else {
hist_entry__tty_annotate(he, evsel, ann);
nd = rb_next(nd);
- /*
-* Since we have a hist_entry per IP for the same
-* symbol, free he->ms.sym->src to signal we already
-* processed this symbol.
-*/
- zfree(¬es->src->cycles_hist);
- zfree(¬es->src);
}
}
}
Thanks,
Namhyung
From: Namhyung Kim
The kernel can allocate a lot of struct perf_event when profiling. For
example, 256 cpu x 8 events x 20 cgroups = 40K instances of the struct
would be allocated on a large system.
The size of struct perf_event in my setup is 1152 byte. As it's
allocated by kmalloc, the a
rnal users too.
Signed-off-by: Namhyung Kim
---
kernel/events/core.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 10f2548211d0..519faf0b7b54 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -11246,13
Another solution would be assigning to temporary variable, checking it,
> but I find it easier to follow with IS_ERR() check in the same function.
> After some time it's still obvious why the check is needed, and with
> temp variable it's possible to make the same mistake.
>
&g
> *unit)
> > return value;
> > }
> >
> > +double convert_unit_double(double value, char *unit)
> > +{
> > + *unit = ' ';
> > +
> > + if (value > 1000.0) {
> > + value /= 1000.0;
> > + *unit = 'K';
> > + }
> > +
> > + if (value > 1000.0) {
> > + value /= 1000.0;
> > + *unit = 'M';
> > + }
> > +
> > + if (value > 1000.0) {
> > + value /= 1000.0;
> > + *unit = 'G';
> > + }
> > +
> > + return value;
> > +}
>
> we have convert_unit function just above doing the same only with
> unsigned long.. let's have one base function with double values and
> another one casting the result to unsigned long
Sounds good.
Thanks,
Namhyung
Hi Jiri,
On Tue, Mar 2, 2021 at 2:24 AM Jiri Olsa wrote:
>
> On Mon, Mar 01, 2021 at 11:04:02PM +0900, Namhyung Kim wrote:
> > The evlist has the maps with its own refcounts so we don't need to set
> > the pointers to NULL. Otherwise following error was reported by Asan.
On Mon, Mar 1, 2021 at 10:33 PM Bayduraev, Alexey V
wrote:
>
> On 01.03.2021 14:44, Namhyung Kim wrote:
> > Hello,
> >
> > On Mon, Mar 1, 2021 at 8:16 PM Bayduraev, Alexey V
> > wrote:
> >>
> >> Hi,
> >>
> >> On 20.11.2020 13:49,
/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x55b620cfc00a in cpu_map__trim_new
/home/namhyung/project/linux/tools/lib/perf/cpumap.c:79
#2 0x55b620cfca2f in perf_cpu_map__read
/home/namhyung/project/linux/tools/lib/perf/cpumap.c:149
#3 0x55b620cfd1ef in cpu_map__read_all_cpu_map
/home
Direct leak of 156 byte(s) in 1 object(s) allocated from:
#0 0x7fc472518e8f in __interceptor_malloc
../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x55e63b378f7a in cpu_map__trim_new
/home/namhyung/project/linux/tools/lib/perf/cpumap.c:79
#2 0x55e63b37a05c in
/namhyung/project/linux/tools/lib/perf/cpumap.c:79
#2 0x55cc6295da1f in perf_cpu_map__read
/home/namhyung/project/linux/tools/lib/perf/cpumap.c:149
#3 0x55cc6295e1df in cpu_map__read_all_cpu_map
/home/namhyung/project/linux/tools/lib/perf/cpumap.c:166
#4 0x55cc6295e1df in perf_cpu_map__new
memory leaks
Direct leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x7fd48cdaa1f8 in __interceptor_realloc
../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:164
#1 0x563e6d5f8d0e in perf_thread_map__realloc
/home/namhyung/project/linux/tools/lib/perf/threadmap.c:23
#2
/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7f091035f6a7 in __vasprintf_internal libio/vasprintf.c:71
SUMMARY: AddressSanitizer: 33 byte(s) leaked in 1 allocation(s).
Signed-off-by: Namhyung Kim
---
tools/perf/tests/attr.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff
and_print tests/builtin-test.c:458
#14 0x55ad9b6f4a53 in __cmd_test tests/builtin-test.c:679
#15 0x55ad9b6f4a53 in cmd_test tests/builtin-test.c:825
#16 0x55ad9b760cc4 in run_builtin
/home/namhyung/project/linux/tools/perf/perf.c:313
#17 0x55ad9b5eaa88 in handle_internal_command
/../../src/libsanitizer/asan/asan_malloc_linux.cpp:164
#1 0x561cf50f4d2e in perf_thread_map__realloc
/home/namhyung/project/linux/tools/lib/perf/threadmap.c:23
#2 0x561cf4eeb949 in thread_map__new_by_tid util/thread_map.c:63
#3 0x561cf4db7fd2 in test__task_exit tests/task-exit.c
or_realloc
../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:164
#1 0x56260d5e8b8e in perf_thread_map__realloc
/home/namhyung/project/linux/tools/lib/perf/threadmap.c:23
#2 0x56260d3df7a9 in thread_map__new_by_tid util/thread_map.c:63
#3 0x56260d2ac6b2 in __test__sw_clock_fre
t applied cleanly. But
I can add them if you want, so please let me know.
It's also available at perf/asan-fix-v1 branch in
git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git
Thanks,
Namhyung
Namhyung Kim (11):
perf test: Fix cpu and thread map leaks in basic mmap
ea in cpu_map__trim_new
/home/namhyung/project/linux/tools/lib/perf/cpumap.c:79
#2 0x564ba21a1a0f in perf_cpu_map__read
/home/namhyung/project/linux/tools/lib/perf/cpumap.c:149
#3 0x564ba21a21cf in cpu_map__read_all_cpu_map
/home/namhyung/project/linux/tools/lib/perf/cpumap.c:166
/asan_malloc_linux.cpp:145
#1 0x7f5444f8c6a7 in __vasprintf_internal libio/vasprintf.c:71
SUMMARY: AddressSanitizer: 14 byte(s) leaked in 1 allocation(s).
test child finished with 1
end
Remove thread map: FAILED!
Signed-off-by: Namhyung Kim
---
tools/perf/tests/thread-map.c | 7 ++-
1
1 - 100 of 4425 matches
Mail list logo
