perf/core improvements and fixes

GIT PULL In review Arnaldo Carvalho de Melo 5 participants 19 messages Apr 13, 2015 – Sep 1, 2017

Subsystems (4)

Memory management perf events Tracing Page cache

lore

Share & tools

lore

Arnaldo Carvalho de Melo

author maintainer

2015-04-13 22:15 UTC #0 lore raw

Hi Ingo,

Please consider pulling,

Best regards,

- Arnaldo

The following changes since commit 066450be419fa48007a9f29e19828f2a86198754:

perf/x86/intel/pt: Clean up the control flow in pt_pmu_hw_init() (2015-04-12 11:21:15 +0200)

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo

for you to fetch changes up to be8d5b1c6b468d10bd2928bbd1a5ca3fd2980402:

perf probe: Fix segfault when probe with lazy_line to file (2015-04-13 17:59:41 -0300)

----------------------------------------------------------------
perf/core improvements and fixes:

New features:

- Analyze page allocator events also in 'perf kmem' (Namhyung Kim)

User visible fixes:

- Fix retprobe 'perf probe' handling when failing to find needed debuginfo (He Kuang)

- lazy_line probe fixes in 'perf probe' (He Kuang)

Infrastructure:

- Record pfn instead of pointer to struct page in tracepoints (Namhyung Kim)

Signed-off-by Arnaldo Carvalho de Melo <[email protected]>

----------------------------------------------------------------
He Kuang (3):
perf probe: Set retprobe flag when probe in address-based alternative mode perf probe: Make --source avaiable when probe with lazy_line perf probe: Fix segfault when probe with lazy_line to file

Namhyung Kim (2):
tracing, mm: Record pfn instead of pointer to struct page perf kmem: Analyze page allocator events also

 include/trace/events/filemap.h         |   8 +-
 include/trace/events/kmem.h            |  42 +--
 include/trace/events/vmscan.h          |   8 +-
 tools/perf/Documentation/perf-kmem.txt |   8 +-
 tools/perf/builtin-kmem.c              | 500 +++++++++++++++++++++++++++++++--
 tools/perf/util/probe-event.c          |   3 +-
 tools/perf/util/probe-event.h          |   2 +
 tools/perf/util/probe-finder.c         |  20 +-
 8 files changed, 540 insertions(+), 51 deletions(-)

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Arnaldo Carvalho de Melo

author maintainer

2015-04-13 22:15 UTC #1 lore raw

PATCH 1/5 tracing, mm: Record pfn instead of pointer to struct page

From: Namhyung Kim <[email protected]>

The struct page is opaque for userspace tools, so it'd be better to save pfn in order to identify page frames.

The textual output of $debugfs/tracing/trace file remains unchanged and only raw (binary) data format is changed - but thanks to libtraceevent, userspace tools which deal with the raw data (like perf and trace-cmd) can parse the format easily. So impact on the userspace will also be minimal.

Signed-off-by Namhyung Kim <[email protected]>

Based-on-patch-by Joonsoo Kim <[email protected]>

Acked-by Ingo Molnar <[email protected]>

Acked-by Steven Rostedt <[email protected]>

Cc David Ahern <[email protected]>

Cc Jiri Olsa <[email protected]>

Cc Minchan Kim <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc [email protected]

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Arnaldo Carvalho de Melo <[email protected]>

---
 include/trace/events/filemap.h |  8 ++++----
 include/trace/events/kmem.h    | 42 +++++++++++++++++++++---------------------
 include/trace/events/vmscan.h  |  8 ++++----
 3 files changed, 29 insertions(+), 29 deletions(-)

include/trace/events/filemap.h +4 -4

index 0421f49a20f7..42febb6bc1d5 100644
@@ -18,14 +18,14 @@ DECLARE_EVENT_CLASS(mm_filemap_op_page_cache,
 	TP_ARGS(page),
 
 	TP_STRUCT__entry(
-		__field(struct page *, page)
+		__field(unsigned long, pfn)
 		__field(unsigned long, i_ino)
 		__field(unsigned long, index)
 		__field(dev_t, s_dev)
 	),
 
 	TP_fast_assign(
-		__entry->page = page;
+		__entry->pfn = page_to_pfn(page);
 		__entry->i_ino = page->mapping->host->i_ino;
 		__entry->index = page->index;
 		if (page->mapping->host->i_sb)

@@ -37,8 +37,8 @@ DECLARE_EVENT_CLASS(mm_filemap_op_page_cache,
 	TP_printk("dev %d:%d ino %lx page=%p pfn=%lu ofs=%lu",
 		MAJOR(__entry->s_dev), MINOR(__entry->s_dev),
 		__entry->i_ino,
-		__entry->page,
-		page_to_pfn(__entry->page),
+		pfn_to_page(__entry->pfn),
+		__entry->pfn,
 		__entry->index << PAGE_SHIFT)
 );

include/trace/events/kmem.h +21 ~~-21~~

128 lines not on this page · raw message

include/trace/events/vmscan.h +4 -4

index 69590b6ffc09..f66476b96264 100644
@@ -336,18 +336,18 @@ TRACE_EVENT(mm_vmscan_writepage,
 	TP_ARGS(page, reclaim_flags),
 
 	TP_STRUCT__entry(
-		__field(struct page *, page)
+		__field(unsigned long, pfn)
 		__field(int, reclaim_flags)
 	),
 
 	TP_fast_assign(
-		__entry->page = page;
+		__entry->pfn = page_to_pfn(page);
 		__entry->reclaim_flags = reclaim_flags;
 	),
 
 	TP_printk("page=%p pfn=%lu flags=%s",
-		__entry->page,
-		page_to_pfn(__entry->page),
+		pfn_to_page(__entry->pfn),
+		__entry->pfn,
 		show_reclaim_flags(__entry->reclaim_flags))
 );

Signature · 7 lines

1.9.3

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Vlastimil Babka

2017-07-31 07:43 UTC #2 lore raw

Re: [PATCH 1/5] tracing, mm: Record pfn instead of pointer to struct page

Quoted 9 lines · Arnaldo Carvalho de Melo

From: Namhyung Kim <[email protected]>
The struct page is opaque for userspace tools, so it'd be better to save pfn in order to identify page frames.
The textual output of $debugfs/tracing/trace file remains unchanged and only raw (binary) data format is changed - but thanks to libtraceevent, userspace tools which deal with the raw data (like perf and trace-cmd) can parse the format easily.

Hmm it seems trace-cmd doesn't work that well, at least on current x86_64 kernel where I noticed it:

trace-cmd-22020 [003] 105219.542610: mm_page_alloc: [FAILED TO PARSE] pfn=0x165cb4 order=0 gfp_flags=29491274 migratetype=1

I'm quite sure it's due to the "page=%p" part, which uses pfn_to_page(). The events/kmem/mm_page_alloc/format file contains this for page:

REC->pfn != -1UL ? (((struct page *)vmemmap_base) + (REC->pfn)) : ((void *)0)

I think userspace can't know vmmemap_base nor the implied sizeof(struct page) for pointer arithmetic?

On older 4.4-based kernel:

REC->pfn != -1UL ? (((struct page *)(0xffffea0000000000UL)) + (REC->pfn)) : ((void *)0)

This also fails to parse, so it must be the struct page part?

I think the problem is, even if ve solve this with some more preprocessor trickery to make the format file contain only constant numbers, pfn_to_page() on e.g. sparse memory model without vmmemap is more complicated than simple arithmetic, and can't be exported in the format file.

I'm afraid that to support userspace parsing of the trace data, we will have to store both struct page and pfn... or perhaps give up on reporting the struct page pointer completely. Thoughts?

Quoted 210 lines

So impact on the userspace will also be
minimal.

Signed-off-by Namhyung Kim <[email protected]>

Based-on-patch-by Joonsoo Kim <[email protected]>

Acked-by Ingo Molnar <[email protected]>

Acked-by Steven Rostedt <[email protected]>

Cc David Ahern <[email protected]>

Cc Jiri Olsa <[email protected]>

Cc Minchan Kim <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc [email protected]

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Arnaldo Carvalho de Melo <[email protected]>

---
 include/trace/events/filemap.h |  8 ++++----
 include/trace/events/kmem.h    | 42 +++++++++++++++++++++---------------------
 include/trace/events/vmscan.h  |  8 ++++----
 3 files changed, 29 insertions(+), 29 deletions(-)

include/trace/events/filemap.h +4 -4

index 0421f49a20f7..42febb6bc1d5 100644
@@ -18,14 +18,14 @@ DECLARE_EVENT_CLASS(mm_filemap_op_page_cache,
 	TP_ARGS(page),
 
 	TP_STRUCT__entry(
-		__field(struct page *, page)
+		__field(unsigned long, pfn)
 		__field(unsigned long, i_ino)
 		__field(unsigned long, index)
 		__field(dev_t, s_dev)
 	),
 
 	TP_fast_assign(
-		__entry->page = page;
+		__entry->pfn = page_to_pfn(page);
 		__entry->i_ino = page->mapping->host->i_ino;
 		__entry->index = page->index;
 		if (page->mapping->host->i_sb)

@@ -37,8 +37,8 @@ DECLARE_EVENT_CLASS(mm_filemap_op_page_cache,
 	TP_printk("dev %d:%d ino %lx page=%p pfn=%lu ofs=%lu",
 		MAJOR(__entry->s_dev), MINOR(__entry->s_dev),
 		__entry->i_ino,
-		__entry->page,
-		page_to_pfn(__entry->page),
+		pfn_to_page(__entry->pfn),
+		__entry->pfn,
 		__entry->index << PAGE_SHIFT)
 );

include/trace/events/kmem.h +21 ~~-21~~

index 4ad10baecd4d..81ea59812117 100644
@@ -154,18 +154,18 @@ TRACE_EVENT(mm_page_free,
 	TP_ARGS(page, order),
 
 	TP_STRUCT__entry(
-		__field(	struct page *,	page		)
+		__field(	unsigned long,	pfn		)
 		__field(	unsigned int,	order		)
 	),
 
 	TP_fast_assign(
-		__entry->page		= page;
+		__entry->pfn		= page_to_pfn(page);
 		__entry->order		= order;
 	),
 
 	TP_printk("page=%p pfn=%lu order=%d",
-			__entry->page,
-			page_to_pfn(__entry->page),
+			pfn_to_page(__entry->pfn),
+			__entry->pfn,
 			__entry->order)
 );

@@ -176,18 +176,18 @@ TRACE_EVENT(mm_page_free_batched,
 	TP_ARGS(page, cold),
 
 	TP_STRUCT__entry(
-		__field(	struct page *,	page		)
+		__field(	unsigned long,	pfn		)
 		__field(	int,		cold		)
 	),
 
 	TP_fast_assign(
-		__entry->page		= page;
+		__entry->pfn		= page_to_pfn(page);
 		__entry->cold		= cold;
 	),
 
 	TP_printk("page=%p pfn=%lu order=0 cold=%d",
-			__entry->page,
-			page_to_pfn(__entry->page),
+			pfn_to_page(__entry->pfn),
+			__entry->pfn,
 			__entry->cold)
 );

@@ -199,22 +199,22 @@ TRACE_EVENT(mm_page_alloc,
 	TP_ARGS(page, order, gfp_flags, migratetype),
 
 	TP_STRUCT__entry(
-		__field(	struct page *,	page		)
+		__field(	unsigned long,	pfn		)
 		__field(	unsigned int,	order		)
 		__field(	gfp_t,		gfp_flags	)
 		__field(	int,		migratetype	)
 	),
 
 	TP_fast_assign(
-		__entry->page		= page;
+		__entry->pfn		= page ? page_to_pfn(page) : -1UL;
 		__entry->order		= order;
 		__entry->gfp_flags	= gfp_flags;
 		__entry->migratetype	= migratetype;
 	),
 
 	TP_printk("page=%p pfn=%lu order=%d migratetype=%d gfp_flags=%s",
-		__entry->page,
-		__entry->page ? page_to_pfn(__entry->page) : 0,
+		__entry->pfn != -1UL ? pfn_to_page(__entry->pfn) : NULL,
+		__entry->pfn != -1UL ? __entry->pfn : 0,
 		__entry->order,
 		__entry->migratetype,
 		show_gfp_flags(__entry->gfp_flags))

@@ -227,20 +227,20 @@ DECLARE_EVENT_CLASS(mm_page,
 	TP_ARGS(page, order, migratetype),
 
 	TP_STRUCT__entry(
-		__field(	struct page *,	page		)
+		__field(	unsigned long,	pfn		)
 		__field(	unsigned int,	order		)
 		__field(	int,		migratetype	)
 	),
 
 	TP_fast_assign(
-		__entry->page		= page;
+		__entry->pfn		= page ? page_to_pfn(page) : -1UL;
 		__entry->order		= order;
 		__entry->migratetype	= migratetype;
 	),
 
 	TP_printk("page=%p pfn=%lu order=%u migratetype=%d percpu_refill=%d",
-		__entry->page,
-		__entry->page ? page_to_pfn(__entry->page) : 0,
+		__entry->pfn != -1UL ? pfn_to_page(__entry->pfn) : NULL,
+		__entry->pfn != -1UL ? __entry->pfn : 0,
 		__entry->order,
 		__entry->migratetype,
 		__entry->order == 0)

@@ -260,7 +260,7 @@ DEFINE_EVENT_PRINT(mm_page, mm_page_pcpu_drain,
 	TP_ARGS(page, order, migratetype),
 
 	TP_printk("page=%p pfn=%lu order=%d migratetype=%d",
-		__entry->page, page_to_pfn(__entry->page),
+		pfn_to_page(__entry->pfn), __entry->pfn,
 		__entry->order, __entry->migratetype)
 );

@@ -275,7 +275,7 @@ TRACE_EVENT(mm_page_alloc_extfrag,
 		alloc_migratetype, fallback_migratetype),
 
 	TP_STRUCT__entry(
-		__field(	struct page *,	page			)
+		__field(	unsigned long,	pfn			)
 		__field(	int,		alloc_order		)
 		__field(	int,		fallback_order		)
 		__field(	int,		alloc_migratetype	)

@@ -284,7 +284,7 @@ TRACE_EVENT(mm_page_alloc_extfrag,
 	),
 
 	TP_fast_assign(
-		__entry->page			= page;
+		__entry->pfn			= page_to_pfn(page);
 		__entry->alloc_order		= alloc_order;
 		__entry->fallback_order		= fallback_order;
 		__entry->alloc_migratetype	= alloc_migratetype;

@@ -294,8 +294,8 @@ TRACE_EVENT(mm_page_alloc_extfrag,
 	),
 
 	TP_printk("page=%p pfn=%lu alloc_order=%d fallback_order=%d pageblock_order=%d alloc_migratetype=%d fallback_migratetype=%d fragmenting=%d change_ownership=%d",
-		__entry->page,
-		page_to_pfn(__entry->page),
+		pfn_to_page(__entry->pfn),
+		__entry->pfn,
 		__entry->alloc_order,
 		__entry->fallback_order,
 		pageblock_order,

include/trace/events/vmscan.h +2 -2

index 69590b6ffc09..f66476b96264 100644
@@ -336,18 +336,18 @@ TRACE_EVENT(mm_vmscan_writepage,
 	TP_ARGS(page, reclaim_flags),
 
 	TP_STRUCT__entry(
-		__field(struct page *, page)
+		__field(unsigned long, pfn)
 		__field(int, reclaim_flags)
 	),
 
 	TP_fast_assign(
-		__entry->page = page;
+		__entry->pfn = page_to_pfn(page);
 		__entry->reclaim_flags = reclaim_flags;

include/trace/events/vmscan.h TRACE_EVENT(mm_vmscan_writepage, · line 353

Quoted 10 lines

include/trace/events/vmscan.h +2 -2

 	),
 
 	TP_printk("page=%p pfn=%lu flags=%s",
-		__entry->page,
-		page_to_pfn(__entry->page),
+		pfn_to_page(__entry->pfn),
+		__entry->pfn,
 		show_reclaim_flags(__entry->reclaim_flags))
 );

Vlastimil Babka

2017-08-31 11:38 UTC #3 lore raw

Re: [PATCH 1/5] tracing, mm: Record pfn instead of pointer to struct page

Ping?

Quoted 251 lines · Vlastimil Babka

Quoted 9 lines · Arnaldo Carvalho de Melo

From: Namhyung Kim <[email protected]>
The struct page is opaque for userspace tools, so it'd be better to save pfn in order to identify page frames.
The textual output of $debugfs/tracing/trace file remains unchanged and only raw (binary) data format is changed - but thanks to libtraceevent, userspace tools which deal with the raw data (like perf and trace-cmd) can parse the format easily.

Hmm it seems trace-cmd doesn't work that well, at least on current x86_64 kernel where I noticed it:

trace-cmd-22020 [003] 105219.542610: mm_page_alloc: [FAILED TO PARSE] pfn=0x165cb4 order=0 gfp_flags=29491274 migratetype=1

I'm quite sure it's due to the "page=%p" part, which uses pfn_to_page(). The events/kmem/mm_page_alloc/format file contains this for page:

REC->pfn != -1UL ? (((struct page *)vmemmap_base) + (REC->pfn)) : ((void *)0)

I think userspace can't know vmmemap_base nor the implied sizeof(struct page) for pointer arithmetic?

On older 4.4-based kernel:

REC->pfn != -1UL ? (((struct page *)(0xffffea0000000000UL)) + (REC->pfn)) : ((void *)0)

This also fails to parse, so it must be the struct page part?

I'm afraid that to support userspace parsing of the trace data, we will have to store both struct page and pfn... or perhaps give up on reporting the struct page pointer completely. Thoughts?

Quoted 211 lines

So impact on the userspace will also be
minimal.

Signed-off-by Namhyung Kim <[email protected]>

Based-on-patch-by Joonsoo Kim <[email protected]>

Acked-by Ingo Molnar <[email protected]>

Acked-by Steven Rostedt <[email protected]>

Cc David Ahern <[email protected]>

Cc Jiri Olsa <[email protected]>

Cc Minchan Kim <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc [email protected]

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Arnaldo Carvalho de Melo <[email protected]>

---
 include/trace/events/filemap.h |  8 ++++----
 include/trace/events/kmem.h    | 42 +++++++++++++++++++++---------------------
 include/trace/events/vmscan.h  |  8 ++++----
 3 files changed, 29 insertions(+), 29 deletions(-)

include/trace/events/filemap.h +4 -4

index 0421f49a20f7..42febb6bc1d5 100644
@@ -18,14 +18,14 @@ DECLARE_EVENT_CLASS(mm_filemap_op_page_cache,
 	TP_ARGS(page),
 
 	TP_STRUCT__entry(
-		__field(struct page *, page)
+		__field(unsigned long, pfn)
 		__field(unsigned long, i_ino)
 		__field(unsigned long, index)
 		__field(dev_t, s_dev)
 	),
 
 	TP_fast_assign(
-		__entry->page = page;
+		__entry->pfn = page_to_pfn(page);
 		__entry->i_ino = page->mapping->host->i_ino;
 		__entry->index = page->index;
 		if (page->mapping->host->i_sb)

@@ -37,8 +37,8 @@ DECLARE_EVENT_CLASS(mm_filemap_op_page_cache,
 	TP_printk("dev %d:%d ino %lx page=%p pfn=%lu ofs=%lu",
 		MAJOR(__entry->s_dev), MINOR(__entry->s_dev),
 		__entry->i_ino,
-		__entry->page,
-		page_to_pfn(__entry->page),
+		pfn_to_page(__entry->pfn),
+		__entry->pfn,
 		__entry->index << PAGE_SHIFT)
 );

include/trace/events/kmem.h +21 ~~-21~~

index 4ad10baecd4d..81ea59812117 100644
@@ -154,18 +154,18 @@ TRACE_EVENT(mm_page_free,
 	TP_ARGS(page, order),
 
 	TP_STRUCT__entry(
-		__field(	struct page *,	page		)
+		__field(	unsigned long,	pfn		)
 		__field(	unsigned int,	order		)
 	),
 
 	TP_fast_assign(
-		__entry->page		= page;
+		__entry->pfn		= page_to_pfn(page);
 		__entry->order		= order;
 	),
 
 	TP_printk("page=%p pfn=%lu order=%d",
-			__entry->page,
-			page_to_pfn(__entry->page),
+			pfn_to_page(__entry->pfn),
+			__entry->pfn,
 			__entry->order)
 );

@@ -176,18 +176,18 @@ TRACE_EVENT(mm_page_free_batched,
 	TP_ARGS(page, cold),
 
 	TP_STRUCT__entry(
-		__field(	struct page *,	page		)
+		__field(	unsigned long,	pfn		)
 		__field(	int,		cold		)
 	),
 
 	TP_fast_assign(
-		__entry->page		= page;
+		__entry->pfn		= page_to_pfn(page);
 		__entry->cold		= cold;
 	),
 
 	TP_printk("page=%p pfn=%lu order=0 cold=%d",
-			__entry->page,
-			page_to_pfn(__entry->page),
+			pfn_to_page(__entry->pfn),
+			__entry->pfn,
 			__entry->cold)
 );

@@ -199,22 +199,22 @@ TRACE_EVENT(mm_page_alloc,
 	TP_ARGS(page, order, gfp_flags, migratetype),
 
 	TP_STRUCT__entry(
-		__field(	struct page *,	page		)
+		__field(	unsigned long,	pfn		)
 		__field(	unsigned int,	order		)
 		__field(	gfp_t,		gfp_flags	)
 		__field(	int,		migratetype	)
 	),
 
 	TP_fast_assign(
-		__entry->page		= page;
+		__entry->pfn		= page ? page_to_pfn(page) : -1UL;
 		__entry->order		= order;
 		__entry->gfp_flags	= gfp_flags;
 		__entry->migratetype	= migratetype;
 	),
 
 	TP_printk("page=%p pfn=%lu order=%d migratetype=%d gfp_flags=%s",
-		__entry->page,
-		__entry->page ? page_to_pfn(__entry->page) : 0,
+		__entry->pfn != -1UL ? pfn_to_page(__entry->pfn) : NULL,
+		__entry->pfn != -1UL ? __entry->pfn : 0,
 		__entry->order,
 		__entry->migratetype,
 		show_gfp_flags(__entry->gfp_flags))

@@ -227,20 +227,20 @@ DECLARE_EVENT_CLASS(mm_page,
 	TP_ARGS(page, order, migratetype),
 
 	TP_STRUCT__entry(
-		__field(	struct page *,	page		)
+		__field(	unsigned long,	pfn		)
 		__field(	unsigned int,	order		)
 		__field(	int,		migratetype	)
 	),
 
 	TP_fast_assign(
-		__entry->page		= page;
+		__entry->pfn		= page ? page_to_pfn(page) : -1UL;
 		__entry->order		= order;
 		__entry->migratetype	= migratetype;
 	),
 
 	TP_printk("page=%p pfn=%lu order=%u migratetype=%d percpu_refill=%d",
-		__entry->page,
-		__entry->page ? page_to_pfn(__entry->page) : 0,
+		__entry->pfn != -1UL ? pfn_to_page(__entry->pfn) : NULL,
+		__entry->pfn != -1UL ? __entry->pfn : 0,
 		__entry->order,
 		__entry->migratetype,
 		__entry->order == 0)

@@ -260,7 +260,7 @@ DEFINE_EVENT_PRINT(mm_page, mm_page_pcpu_drain,
 	TP_ARGS(page, order, migratetype),
 
 	TP_printk("page=%p pfn=%lu order=%d migratetype=%d",
-		__entry->page, page_to_pfn(__entry->page),
+		pfn_to_page(__entry->pfn), __entry->pfn,
 		__entry->order, __entry->migratetype)
 );

@@ -275,7 +275,7 @@ TRACE_EVENT(mm_page_alloc_extfrag,
 		alloc_migratetype, fallback_migratetype),
 
 	TP_STRUCT__entry(
-		__field(	struct page *,	page			)
+		__field(	unsigned long,	pfn			)
 		__field(	int,		alloc_order		)
 		__field(	int,		fallback_order		)
 		__field(	int,		alloc_migratetype	)

@@ -284,7 +284,7 @@ TRACE_EVENT(mm_page_alloc_extfrag,
 	),
 
 	TP_fast_assign(
-		__entry->page			= page;
+		__entry->pfn			= page_to_pfn(page);
 		__entry->alloc_order		= alloc_order;
 		__entry->fallback_order		= fallback_order;
 		__entry->alloc_migratetype	= alloc_migratetype;

@@ -294,8 +294,8 @@ TRACE_EVENT(mm_page_alloc_extfrag,
 	),
 
 	TP_printk("page=%p pfn=%lu alloc_order=%d fallback_order=%d pageblock_order=%d alloc_migratetype=%d fallback_migratetype=%d fragmenting=%d change_ownership=%d",
-		__entry->page,
-		page_to_pfn(__entry->page),
+		pfn_to_page(__entry->pfn),
+		__entry->pfn,
 		__entry->alloc_order,
 		__entry->fallback_order,
 		pageblock_order,

include/trace/events/vmscan.h +2 -2

index 69590b6ffc09..f66476b96264 100644
@@ -336,18 +336,18 @@ TRACE_EVENT(mm_vmscan_writepage,
 	TP_ARGS(page, reclaim_flags),
 
 	TP_STRUCT__entry(
-		__field(struct page *, page)
+		__field(unsigned long, pfn)
 		__field(int, reclaim_flags)
 	),
 
 	TP_fast_assign(
-		__entry->page = page;
+		__entry->pfn = page_to_pfn(page);
 		__entry->reclaim_flags = reclaim_flags;
 	),

Quoted 16 lines

include/trace/events/vmscan.h TRACE_EVENT(mm_vmscan_writepage, · line 353
Quoted 9 lines
include/trace/events/vmscan.h +2 -2
 	TP_printk("page=%p pfn=%lu flags=%s",
-		__entry->page,
-		page_to_pfn(__entry->page),
+		pfn_to_page(__entry->pfn),
+		__entry->pfn,
 		show_reclaim_flags(__entry->reclaim_flags))
 );
 
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Steven Rostedt

maintainer

2017-08-31 13:43 UTC #4 lore raw

Re: [PATCH 1/5] tracing, mm: Record pfn instead of pointer to struct page

In reply to Vlastimil Babka

Quoted 11 lines · On Mon, 31 Jul 2017 09:43:41 +0200 Vlastimil Babka <[email protected]> wrote:

Quoted 9 lines · Arnaldo Carvalho de Melo
From: Namhyung Kim <[email protected]>
The struct page is opaque for userspace tools, so it'd be better to save pfn in order to identify page frames.
The textual output of $debugfs/tracing/trace file remains unchanged and only raw (binary) data format is changed - but thanks to libtraceevent, userspace tools which deal with the raw data (like perf and trace-cmd) can parse the format easily.

Quoted 4 lines

Hmm it seems trace-cmd doesn't work that well, at least on current x86_64 kernel where I noticed it:
trace-cmd-22020 [003] 105219.542610: mm_page_alloc: [FAILED TO PARSE] pfn=0x165cb4 order=0 gfp_flags=29491274 migratetype=1

Which version of trace-cmd failed? It parses for me. Hmm, the vmemmap_base isn't in the event format file. It's the actually address. That's probably what failed to parse.

Quoted 5 lines

I'm quite sure it's due to the "page=%p" part, which uses pfn_to_page(). The events/kmem/mm_page_alloc/format file contains this for page:
REC->pfn != -1UL ? (((struct page *)vmemmap_base) + (REC->pfn)) : ((void *)0)

But yeah, I think the output is wrong. I just ran this:

page=0xffffea00000a62f4 pfn=680692 order=0 migratetype=0 gfp_flags=GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_NOTRACK

But running it with trace-cmd report -R (raw format):

mm_page_alloc: pfn=0xa62f4 order=0 gfp_flags=24150208 migratetype=0

The parser currently ignores types, so it doesn't do pointer arithmetic correctly, and would be hard to here as it doesn't know the size of the struct page. What could work is if we changed the printf fmt to be:

(unsigned long)(0xffffea0000000000UL) + (REC->pfn * sizeof(struct page))

Quoted 7 lines

I think userspace can't know vmmemap_base nor the implied sizeof(struct page) for pointer arithmetic?
On older 4.4-based kernel:
REC->pfn != -1UL ? (((struct page *)(0xffffea0000000000UL)) + (REC->pfn)) : ((void *)0)

This is what I have on 4.13-rc7

Quoted 2 lines

This also fails to parse, so it must be the struct page part?

Again, what version of trace-cmd do you have?

Quoted 10 lines

I think the problem is, even if ve solve this with some more preprocessor trickery to make the format file contain only constant numbers, pfn_to_page() on e.g. sparse memory model without vmmemap is more complicated than simple arithmetic, and can't be exported in the format file.
I'm afraid that to support userspace parsing of the trace data, we will have to store both struct page and pfn... or perhaps give up on reporting the struct page pointer completely. Thoughts?

Had some thoughts up above.

-- Steve

Vlastimil Babka

2017-08-31 14:31 UTC #5 lore raw

Re: [PATCH 1/5] tracing, mm: Record pfn instead of pointer to struct page

Quoted 13 lines · Steven Rostedt

Quoted 11 lines · On Mon, 31 Jul 2017 09:43:41 +0200 Vlastimil Babka <[email protected]> wrote:
Quoted 9 lines · Arnaldo Carvalho de Melo
From: Namhyung Kim <[email protected]>
The struct page is opaque for userspace tools, so it'd be better to save pfn in order to identify page frames.
The textual output of $debugfs/tracing/trace file remains unchanged and only raw (binary) data format is changed - but thanks to libtraceevent, userspace tools which deal with the raw data (like perf and trace-cmd) can parse the format easily.

Quoted 8 lines

Quoted 4 lines
Hmm it seems trace-cmd doesn't work that well, at least on current x86_64 kernel where I noticed it:
trace-cmd-22020 [003] 105219.542610: mm_page_alloc: [FAILED TO PARSE] pfn=0x165cb4 order=0 gfp_flags=29491274 migratetype=1
Which version of trace-cmd failed? It parses for me. Hmm, the vmemmap_base isn't in the event format file. It's the actually address. That's probably what failed to parse.

Mine says 2.6. With 4.13-rc6 I get FAILED TO PARSE.

Quoted 29 lines

Quoted 6 lines
I'm quite sure it's due to the "page=%p" part, which uses pfn_to_page(). The events/kmem/mm_page_alloc/format file contains this for page:
REC->pfn != -1UL ? (((struct page *)vmemmap_base) + (REC->pfn)) : ((void *)0)
But yeah, I think the output is wrong. I just ran this:
page=0xffffea00000a62f4 pfn=680692 order=0 migratetype=0 gfp_flags=GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_NOTRACK
But running it with trace-cmd report -R (raw format):
mm_page_alloc: pfn=0xa62f4 order=0 gfp_flags=24150208 migratetype=0
The parser currently ignores types, so it doesn't do pointer arithmetic correctly, and would be hard to here as it doesn't know the size of the struct page. What could work is if we changed the printf fmt to be:
(unsigned long)(0xffffea0000000000UL) + (REC->pfn * sizeof(struct page))
Quoted 6 lines
I think userspace can't know vmmemap_base nor the implied sizeof(struct page) for pointer arithmetic?
On older 4.4-based kernel:

Quoted 8 lines

Quoted 1 line
REC->pfn != -1UL ? (((struct page *)(0xffffea0000000000UL)) + (REC->pfn)) : ((void *)0)
This is what I have on 4.13-rc7
Quoted 2 lines
This also fails to parse, so it must be the struct page part?
Again, what version of trace-cmd do you have?

On the older distro it was 2.0.4

Quoted 8 lines

Quoted 8 lines
I think the problem is, even if ve solve this with some more preprocessor trickery to make the format file contain only constant numbers, pfn_to_page() on e.g. sparse memory model without vmmemap is more complicated than simple arithmetic, and can't be exported in the format file.

Quoted 5 lines

Quoted 3 lines
I'm afraid that to support userspace parsing of the trace data, we will have to store both struct page and pfn... or perhaps give up on reporting the struct page pointer completely. Thoughts?
Had some thoughts up above.

Yeah, it could be made to work for some configurations, but see the part about "sparse memory model without vmemmap" above.

Quoted 2 lines

-- Steve

Steven Rostedt

maintainer

2017-08-31 14:44 UTC #6 lore raw

Re: [PATCH 1/5] tracing, mm: Record pfn instead of pointer to struct page

Quoted 5 lines · On Thu, 31 Aug 2017 16:31:36 +0200 Vlastimil Babka <[email protected]> wrote:

Quoted 3 lines
Which version of trace-cmd failed? It parses for me. Hmm, the vmemmap_base isn't in the event format file. It's the actually address. That's probably what failed to parse.
Mine says 2.6. With 4.13-rc6 I get FAILED TO PARSE.

Right, but you have the vmemmap_base in the event format, which can't be parsed by userspace because it has no idea what the value of the vmemmap_base is.

Quoted 14 lines

Quoted 14 lines
Quoted 13 lines
I'm quite sure it's due to the "page=%p" part, which uses pfn_to_page(). The events/kmem/mm_page_alloc/format file contains this for page:
REC->pfn != -1UL ? (((struct page *)vmemmap_base) + (REC->pfn)) : ((void *)0)
On older 4.4-based kernel:
REC->pfn != -1UL ? (((struct page *)(0xffffea0000000000UL)) + (REC->pfn)) : ((void *)0)

Quoted 8 lines

Quoted 6 lines
This is what I have on 4.13-rc7
Quoted 2 lines
This also fails to parse, so it must be the struct page part?
Again, what version of trace-cmd do you have?
On the older distro it was 2.0.4

Right. That's probably why it failed to parse here. If you installed the latest trace-cmd from the git repo, it probably will parse fine.

Quoted 9 lines

Quoted 9 lines
Quoted 9 lines
I think the problem is, even if ve solve this with some more preprocessor trickery to make the format file contain only constant numbers, pfn_to_page() on e.g. sparse memory model without vmmemap is more complicated than simple arithmetic, and can't be exported in the format file.

Quoted 8 lines

Quoted 5 lines
Quoted 3 lines
I'm afraid that to support userspace parsing of the trace data, we will have to store both struct page and pfn... or perhaps give up on reporting the struct page pointer completely. Thoughts?
Had some thoughts up above.
Yeah, it could be made to work for some configurations, but see the part about "sparse memory model without vmemmap" above.

Right, but that should work with the latest trace-cmd. Does it?

-- Steve

Vlastimil Babka

2017-09-01 08:16 UTC #7 lore raw

Re: [PATCH 1/5] tracing, mm: Record pfn instead of pointer to struct page

Quoted 8 lines · Steven Rostedt

Quoted 4 lines · On Thu, 31 Aug 2017 16:31:36 +0200 Vlastimil Babka <[email protected]> wrote:
Quoted 3 lines
Which version of trace-cmd failed? It parses for me. Hmm, the vmemmap_base isn't in the event format file. It's the actually address. That's probably what failed to parse.

Quoted 5 lines

Quoted 1 line
Mine says 2.6. With 4.13-rc6 I get FAILED TO PARSE.
Right, but you have the vmemmap_base in the event format, which can't be parsed by userspace because it has no idea what the value of the vmemmap_base is.

This seems to be caused by CONFIG_RANDOMIZE_MEMORY. If we somehow put the value in the format file, it's an info leak? (but I guess kernels that care must have ftrace disabled anyway :)

Quoted 18 lines

Quoted 18 lines
Quoted 18 lines
Quoted 17 lines
I'm quite sure it's due to the "page=%p" part, which uses pfn_to_page(). The events/kmem/mm_page_alloc/format file contains this for page:
REC->pfn != -1UL ? (((struct page *)vmemmap_base) + (REC->pfn)) : ((void *)0)
I think the problem is, even if ve solve this with some more preprocessor trickery to make the format file contain only constant numbers, pfn_to_page() on e.g. sparse memory model without vmmemap is more complicated than simple arithmetic, and can't be exported in the format file.
I'm afraid that to support userspace parsing of the trace data, we will have to store both struct page and pfn... or perhaps give up on reporting the struct page pointer completely. Thoughts?

Quoted 6 lines

Quoted 4 lines
Quoted 1 line
Had some thoughts up above.
Yeah, it could be made to work for some configurations, but see the part about "sparse memory model without vmemmap" above.
Right, but that should work with the latest trace-cmd. Does it?

Hmm, by "sparse memory model without vmemmap" I don't mean there's a number instead of "vmemmap_base". I mean CONFIG_SPARSEMEM=y

Then __pfn_to_page() looks like this:

#define __page_to_pfn(pg)                                       \
({      const struct page *__pg = (pg);                         \
        int __sec = page_to_section(__pg);                      \
        (unsigned long)(__pg - __section_mem_map_addr(__nr_to_section(__sec))); \
})

Then the part of format file looks like this:

REC->pfn != -1UL ? ({ unsigned long __pfn = (REC->pfn); struct mem_section *__sec = __pfn_to_section(__pfn); __section_mem_map_addr(__sec) + __pfn; }) : ((void *)0)

The section things involve some array lookups, so I don't see how we could pass it to tracing userspace. Would we want to special-case this config to store both pfn and struct page in the trace frame? And make sure the simpler ones work despite all the exsisting gotchas? I'd rather say we should either store both pfn and page pointer, or just throw away the page pointer as the pfn is enough to e.g. match alloc and free, and also much more deterministic.

Quoted 2 lines

-- Steve

Steven Rostedt

maintainer

2017-09-01 11:15 UTC #8 lore raw

Re: [PATCH 1/5] tracing, mm: Record pfn instead of pointer to struct page

Quoted 13 lines · On Fri, 1 Sep 2017 10:16:21 +0200 Vlastimil Babka <[email protected]> wrote:

Quoted 1 line
Right, but that should work with the latest trace-cmd. Does it?
Hmm, by "sparse memory model without vmemmap" I don't mean there's a number instead of "vmemmap_base". I mean CONFIG_SPARSEMEM=y
Then __pfn_to_page() looks like this:
#define __page_to_pfn(pg)                                       \
({      const struct page *__pg = (pg);                         \
        int __sec = page_to_section(__pg);                      \
        (unsigned long)(__pg - __section_mem_map_addr(__nr_to_section(__sec))); \
})

Quoted 3 lines

Then the part of format file looks like this:
REC->pfn != -1UL ? ({ unsigned long __pfn = (REC->pfn); struct mem_section *__sec = __pfn_to_section(__pfn); __section_mem_map_addr(__sec) + __pfn; }) : ((void *)0)

Ouch.

Quoted 8 lines

The section things involve some array lookups, so I don't see how we could pass it to tracing userspace. Would we want to special-case this config to store both pfn and struct page in the trace frame? And make sure the simpler ones work despite all the exsisting gotchas? I'd rather say we should either store both pfn and page pointer, or just throw away the page pointer as the pfn is enough to e.g. match alloc and free, and also much more deterministic.

Write up a patch and we'll take a look.

-- Steve

Arnaldo Carvalho de Melo

author maintainer

2015-04-13 22:15 UTC #9 lore raw

PATCH 2/5 perf kmem: Analyze page allocator events also

In reply to Arnaldo Carvalho de Melo

From: Namhyung Kim <[email protected]>

The perf kmem command records and analyze kernel memory allocation only for SLAB objects. This patch implement a simple page allocator analyzer using kmem:mm_page_alloc and kmem:mm_page_free events.

It adds two new options of --slab and --page. The --slab option is for analyzing SLAB allocator and that's what perf kmem currently does.

The new --page option enables page allocator events and analyze kernel memory usage in page unit. Currently, 'stat --alloc' subcommand is implemented only.

If none of these --slab nor --page is specified, --slab is implied.

First run 'perf kmem record' to generate a suitable perf.data file:

  # perf kmem record --page sleep 5

Then run 'perf kmem stat' to postprocess the perf.data file:

  # perf kmem stat --page --alloc --line 10

            4045014 |               16 |        1 |     2 |  RECLAIM |  00285250
            4143980 |               16 |        1 |     2 |  RECLAIM |  00285250
            3938658 |               16 |        1 |     2 |  RECLAIM |  00285250
            4045400 |               16 |        1 |     2 |  RECLAIM |  00285250
            3568708 |               16 |        1 |     2 |  RECLAIM |  00285250
            3729824 |               16 |        1 |     2 |  RECLAIM |  00285250
            3657210 |               16 |        1 |     2 |  RECLAIM |  00285250
            4120750 |               16 |        1 |     2 |  RECLAIM |  00285250
            3678850 |               16 |        1 |     2 |  RECLAIM |  00285250
            3693874 |               16 |        1 |     2 |  RECLAIM |  00285250

... | ... | ... | ... | ... | ...
-------------------------------------------------------------------------------

SUMMARY (page allocator)
========================

  Total allocation requests     :           44,260   [          177,256 KB ]
  Total free requests           :              117   [              468 KB ]

  Total alloc+freed requests    :               49   [              196 KB ]
  Total alloc-only requests     :           44,211   [          177,060 KB ]
  Total free-only requests      :               68   [              272 KB ]

Total allocation failures : 0 [ 0 KB ]

Order Unmovable Reclaimable Movable Reserved CMA/Isolated
----- ------------ ------------ ------------ ------------ ------------

      0            32             .        44,210             .             .
      1             .             .             .             .             .
      2             .            18             .             .             .
      3             .             .             .             .             .
      4             .             .             .             .             .
      5             .             .             .             .             .
      6             .             .             .             .             .
      7             .             .             .             .             .
      8             .             .             .             .             .
      9             .             .             .             .             .
     10             .             .             .             .             .

Signed-off-by Namhyung Kim <[email protected]>

Tested-by Arnaldo Carvalho de Melo <[email protected]>

Cc David Ahern <[email protected]>

Cc Jiri Olsa <[email protected]>

Cc Joonsoo Kim <[email protected]>

Cc Minchan Kim <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc [email protected]

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Arnaldo Carvalho de Melo <[email protected]>

---
 tools/perf/Documentation/perf-kmem.txt |   8 +-
 tools/perf/builtin-kmem.c              | 500 +++++++++++++++++++++++++++++++--
 2 files changed, 491 insertions(+), 17 deletions(-)

tools/perf/Documentation/perf-kmem.txt +7 -1

index 150253cc3c97..23219c65c16f 100644
@@ -3,7 +3,7 @@ perf-kmem(1)
 
 NAME
 ----
-perf-kmem - Tool to trace/measure kernel memory(slab) properties
+perf-kmem - Tool to trace/measure kernel memory properties
 
 SYNOPSIS
 --------

@@ -46,6 +46,12 @@ OPTIONS
 --raw-ip::
 	Print raw ip instead of symbol
 
+--slab::
+	Analyze SLAB allocator events.
+
+--page::
+	Analyze page allocator events
+
 SEE ALSO
 --------
 linkperf:perf-record[1]

tools/perf/builtin-kmem.c +484 ~~-16~~

624 lines not on this page · raw message

Signature · 7 lines

1.9.3

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Arnaldo Carvalho de Melo

author maintainer

2015-04-13 22:16 UTC #10 lore raw

PATCH 3/5 perf probe: Set retprobe flag when probe in address-based alternative mode

In reply to Arnaldo Carvalho de Melo

From: He Kuang <[email protected]>

When perf probe searched in a debuginfo file and failed, it tried with an alternative, in function get_alternative_probe_event():

        memcpy(tmp, &pev->point, sizeof(*tmp));
        memset(&pev->point, 0, sizeof(pev->point));

In this case, it drops the retprobe flag and forgets to set it back in find_alternative_probe_point(), so the problem occurs.

Can be reproduced as following:

  $ perf probe -v -k vmlinux --add='sys_write%return'
  ...
  Added new event:
  Writing event: p:probe/sys_write _stext+1584952
    probe:sys_write      (on sys_write%return)

  $ cat /sys/kernel/debug/tracing/kprobe_events
  p:probe/sys_write _stext+1584952

After this patch:

  $ perf probe -v -k vmlinux --add='sys_write%return'
  Added new event:
  Writing event: r:probe/sys_write SyS_write+0
    probe:sys_write      (on sys_write%return)

  $ cat /sys/kernel/debug/tracing/kprobe_events
  r:probe/sys_write SyS_write

Signed-off-by He Kuang <[email protected]>

Tested-by Arnaldo Carvalho de Melo <[email protected]>

Acked-by Masami Hiramatsu <[email protected]>

Cc Namhyung Kim <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc Wang Nan <[email protected]>

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Arnaldo Carvalho de Melo <[email protected]>

---
 tools/perf/util/probe-event.c | 1 +
 1 file changed, 1 insertion(+)

tools/perf/util/probe-event.c +1 -0

index 30545ce2c712..5483d98236d3 100644
@@ -332,6 +332,7 @@ static int find_alternative_probe_point(struct debuginfo *dinfo,
 	else {
 		result->offset += pp->offset;
 		result->line += pp->line;
+		result->retprobe = pp->retprobe;
 		ret = 0;
 	}

Signature · 1 line

1.9.3

Arnaldo Carvalho de Melo

author maintainer

2015-04-13 22:15 UTC #11 lore raw

PATCH 4/5 perf probe: Make --source avaiable when probe with lazy_line

In reply to Arnaldo Carvalho de Melo

From: He Kuang <[email protected]>

Use get_real_path() to enable --source option when probe with lazy_line pattern.

Before this patch:

  $ perf probe -s ./kernel_src/ -k ./vmlinux --add='fs/super.c;s->s_count=1;'
  Failed to open fs/super.c: No such file or directory
    Error: Failed to add events.

After this patch:

  $ perf probe -s ./kernel_src/ -k ./vmlinux  --add='fs/super.c;s->s_count=1;'
  Added new events:
    probe:_stext         (on @fs/super.c)
    probe:_stext_1       (on @fs/super.c)
  ...

Signed-off-by He Kuang <[email protected]>

Acked-by Masami Hiramatsu <[email protected]>

Cc Namhyung Kim <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc Wang Nan <[email protected]>

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Arnaldo Carvalho de Melo <[email protected]>

---
 tools/perf/util/probe-event.c  |  2 +-
 tools/perf/util/probe-event.h  |  2 ++
 tools/perf/util/probe-finder.c | 18 +++++++++++++++---
 3 files changed, 18 insertions(+), 4 deletions(-)

tools/perf/util/probe-event.c +1 -1

index 5483d98236d3..35ee51a8724f 100644
@@ -661,7 +661,7 @@ static int try_to_find_probe_trace_events(struct perf_probe_event *pev,
  * a newly allocated path on success.
  * Return 0 if file was found and readable, -errno otherwise.
  */
-static int get_real_path(const char *raw_path, const char *comp_dir,
+int get_real_path(const char *raw_path, const char *comp_dir,
 			 char **new_path)
 {
 	const char *prefix = symbol_conf.source_prefix;

tools/perf/util/probe-event.h +2 -0

index d6b783447be9..21809ea9b2b4 100644
@@ -135,6 +135,8 @@ extern int show_available_vars(struct perf_probe_event *pevs, int npevs,
 			       struct strfilter *filter, bool externs);
 extern int show_available_funcs(const char *module, struct strfilter *filter,
 				bool user);
+extern int get_real_path(const char *raw_path, const char *comp_dir,
+			char **new_path);
 
 /* Maximum index number of event-name postfix */
 #define MAX_EVENT_INDEX	1024

tools/perf/util/probe-finder.c +15 -3

index 7831e2d93949..431c12d299a2 100644
@@ -791,11 +791,20 @@ static int find_lazy_match_lines(struct intlist *list,
 	ssize_t len;
 	int count = 0, linenum = 1;
 	char sbuf[STRERR_BUFSIZE];
+	char *realname = NULL;
+	int ret;
 
-	fp = fopen(fname, "r");
+	ret = get_real_path(fname, NULL, &realname);
+	if (ret < 0) {
+		pr_warning("Failed to find source file %s.\n", fname);
+		return ret;
+	}
+
+	fp = fopen(realname, "r");
 	if (!fp) {
-		pr_warning("Failed to open %s: %s\n", fname,
+		pr_warning("Failed to open %s: %s\n", realname,
 			   strerror_r(errno, sbuf, sizeof(sbuf)));
+		free(realname);
 		return -errno;
 	}

@@ -817,7 +826,10 @@ static int find_lazy_match_lines(struct intlist *list,
 	fclose(fp);
 
 	if (count == 0)
-		pr_debug("No matched lines found in %s.\n", fname);
+		pr_debug("No matched lines found in %s.\n", realname);
+
+	free(realname);
+
 	return count;
 }

Signature · 1 line

1.9.3

Arnaldo Carvalho de Melo

author maintainer

2015-04-13 22:15 UTC #12 lore raw

PATCH 5/5 perf probe: Fix segfault when probe with lazy_line to file

In reply to Arnaldo Carvalho de Melo

From: He Kuang <[email protected]>

The first argument passed to find_probe_point_lazy() should be CU die, which will be passed to die_walk_lines() when lazy_line matches. Currently, when we probe with lazy_line pattern to file without function name, NULL pointer is passed and causes a segment fault.

Can be reproduced as following:

  $ perf probe -k vmlinux --add='fs/super.c;s->s_count=1;'
  [ 1958.984658] perf[1020]: segfault at 10 ip 00007fc6e10d8c71 sp
  00007ffcbfaaf900 error 4 in libdw-0.161.so[7fc6e10ce000+34000]
  Segmentation fault

After this patch:

  $ perf probe -k vmlinux --add='fs/super.c;s->s_count=1;'
  Added new event:
  probe:_stext         (on @fs/super.c)

You can now use it in all perf tools, such as:
perf record -e probe:_stext -aR sleep 1

Signed-off-by He Kuang <[email protected]>

Tested-by Arnaldo Carvalho de Melo <[email protected]>

Acked-by Masami Hiramatsu <[email protected]>

Cc Namhyung Kim <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc Wang Nan <[email protected]>

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Arnaldo Carvalho de Melo <[email protected]>

---
 tools/perf/util/probe-finder.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

tools/perf/util/probe-finder.c +1 -1

index 431c12d299a2..e91101b8f60f 100644
@@ -1067,7 +1067,7 @@ static int debuginfo__find_probes(struct debuginfo *dbg,
 			if (pp->function)
 				ret = find_probe_point_by_func(pf);
 			else if (pp->lazy_line)
-				ret = find_probe_point_lazy(NULL, pf);
+				ret = find_probe_point_lazy(&pf->cu_die, pf);
 			else {
 				pf->lno = pp->line;
 				ret = find_probe_point_by_line(pf);

Signature · 1 line

1.9.3

Masami Hiramatsu

2015-04-13 22:33 UTC #13 lore raw

In reply to Arnaldo Carvalho de Melo

Hi, Arnaldo,

Quoted 1 line

perf probe: Make --source avaiable when probe with lazy_line

No, could you pull Naohiro's patch?
I'd like to move get_real_path to probe_finder.c

Thank you,

Quoted 65 lines · Arnaldo Carvalho de Melo

Hi Ingo,
Please consider pulling,
Best regards,
- Arnaldo
The following changes since commit 066450be419fa48007a9f29e19828f2a86198754:
perf/x86/intel/pt: Clean up the control flow in pt_pmu_hw_init() (2015-04-12 11:21:15 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo
for you to fetch changes up to be8d5b1c6b468d10bd2928bbd1a5ca3fd2980402:
perf probe: Fix segfault when probe with lazy_line to file (2015-04-13 17:59:41 -0300)
----------------------------------------------------------------
perf/core improvements and fixes:
New features:
- Analyze page allocator events also in 'perf kmem' (Namhyung Kim)
User visible fixes:
- Fix retprobe 'perf probe' handling when failing to find needed debuginfo (He Kuang)
- lazy_line probe fixes in 'perf probe' (He Kuang)
Infrastructure:
- Record pfn instead of pointer to struct page in tracepoints (Namhyung Kim)
Signed-off-by Arnaldo Carvalho de Melo <[email protected]>
----------------------------------------------------------------
He Kuang (3):
perf probe: Set retprobe flag when probe in address-based alternative mode perf probe: Make --source avaiable when probe with lazy_line perf probe: Fix segfault when probe with lazy_line to file
Namhyung Kim (2):
tracing, mm: Record pfn instead of pointer to struct page perf kmem: Analyze page allocator events also
 include/trace/events/filemap.h         |   8 +-
 include/trace/events/kmem.h            |  42 +--
 include/trace/events/vmscan.h          |   8 +-
 tools/perf/Documentation/perf-kmem.txt |   8 +-
 tools/perf/builtin-kmem.c              | 500 +++++++++++++++++++++++++++++++--
 tools/perf/util/probe-event.c          |   3 +-
 tools/perf/util/probe-event.h          |   2 +
 tools/perf/util/probe-finder.c         |  20 +-
 8 files changed, 540 insertions(+), 51 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Signature · 12 lines

Masami HIRAMATSU
Linux Technology Research Center, System Productivity Research Dept.
Center for Technology Innovation - Systems Engineering
Hitachi, Ltd., Research & Development Group
E-mail: [email protected]


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Arnaldo Carvalho de Melo

author maintainer

2015-04-13 23:09 UTC #14 lore raw

Em Tue, Apr 14, 2015 at 07:33:07AM +0900, Masami Hiramatsu escreveu:

Quoted 6 lines

Hi, Arnaldo,
Quoted 1 line
perf probe: Make --source avaiable when probe with lazy_line
No, could you pull Naohiro's patch?
I'd like to move get_real_path to probe_finder.c

OOps, yeah, you asked for that... Ingo, please ignore this pull request for now, thanks,

- Arnaldo

Quoted 52 lines

Thank you,
Quoted 49 lines · Arnaldo Carvalho de Melo
Hi Ingo,
Please consider pulling,
Best regards,
- Arnaldo
The following changes since commit 066450be419fa48007a9f29e19828f2a86198754:
perf/x86/intel/pt: Clean up the control flow in pt_pmu_hw_init() (2015-04-12 11:21:15 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo
for you to fetch changes up to be8d5b1c6b468d10bd2928bbd1a5ca3fd2980402:
perf probe: Fix segfault when probe with lazy_line to file (2015-04-13 17:59:41 -0300)
----------------------------------------------------------------
perf/core improvements and fixes:
New features:
- Analyze page allocator events also in 'perf kmem' (Namhyung Kim)
User visible fixes:
- Fix retprobe 'perf probe' handling when failing to find needed debuginfo (He Kuang)
- lazy_line probe fixes in 'perf probe' (He Kuang)
Infrastructure:
- Record pfn instead of pointer to struct page in tracepoints (Namhyung Kim)
Signed-off-by Arnaldo Carvalho de Melo <[email protected]>
----------------------------------------------------------------
He Kuang (3):
perf probe: Set retprobe flag when probe in address-based alternative mode perf probe: Make --source avaiable when probe with lazy_line perf probe: Fix segfault when probe with lazy_line to file
Namhyung Kim (2):
tracing, mm: Record pfn instead of pointer to struct page perf kmem: Analyze page allocator events also

Quoted 25 lines

Quoted 16 lines

 include/trace/events/filemap.h         |   8 +-
 include/trace/events/kmem.h            |  42 +--
 include/trace/events/vmscan.h          |   8 +-
 tools/perf/Documentation/perf-kmem.txt |   8 +-
 tools/perf/builtin-kmem.c              | 500 +++++++++++++++++++++++++++++++--
 tools/perf/util/probe-event.c          |   3 +-
 tools/perf/util/probe-event.h          |   2 +
 tools/perf/util/probe-finder.c         |  20 +-
 8 files changed, 540 insertions(+), 51 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Signature · 5 lines

Masami HIRAMATSU
Linux Technology Research Center, System Productivity Research Dept.
Center for Technology Innovation - Systems Engineering
Hitachi, Ltd., Research & Development Group
E-mail: [email protected]

Arnaldo Carvalho de Melo

author maintainer

2015-04-13 23:19 UTC #15 lore raw

Em Mon, Apr 13, 2015 at 08:09:23PM -0300, Arnaldo Carvalho de Melo escreveu:

Quoted 10 lines

Em Tue, Apr 14, 2015 at 07:33:07AM +0900, Masami Hiramatsu escreveu:
Quoted 6 lines
Hi, Arnaldo,
Quoted 1 line
perf probe: Make --source avaiable when probe with lazy_line
No, could you pull Naohiro's patch?
I'd like to move get_real_path to probe_finder.c
OOps, yeah, you asked for that... Ingo, please ignore this pull request for now, thanks,

Ok, I did that and created a perf-core-for-mingo-2, Masami, please check that all is right, ok?

- Arnaldo

The following changes since commit 066450be419fa48007a9f29e19828f2a86198754:

perf/x86/intel/pt: Clean up the control flow in pt_pmu_hw_init() (2015-04-12 11:21:15 +0200)

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo-2

for you to fetch changes up to f19e80c640d58ddfd70f2454ee597f81ba966690:

perf probe: Fix segfault when probe with lazy_line to file (2015-04-13 20:12:21 -0300)

----------------------------------------------------------------
perf/core improvements and fixes:

New features:

- Analyze page allocator events also in 'perf kmem' (Namhyung Kim)

User visible fixes:

- Fix retprobe 'perf probe' handling when failing to find needed debuginfo (He Kuang)

- lazy_line probe fixes in 'perf probe' (Naohiro Aota, He Kuang)

Infrastructure:

- Record pfn instead of pointer to struct page in tracepoints (Namhyung Kim)

Signed-off-by Arnaldo Carvalho de Melo <[email protected]>

----------------------------------------------------------------
He Kuang (2):
perf probe: Set retprobe flag when probe in address-based alternative mode perf probe: Fix segfault when probe with lazy_line to file

Namhyung Kim (2):
tracing, mm: Record pfn instead of pointer to struct page perf kmem: Analyze page allocator events also

Naohiro Aota (1):
perf probe: Find compilation directory path for lazy matching

 include/trace/events/filemap.h         |   8 +-
 include/trace/events/kmem.h            |  42 +--
 include/trace/events/vmscan.h          |   8 +-
 tools/perf/Documentation/perf-kmem.txt |   8 +-
 tools/perf/builtin-kmem.c              | 500 +++++++++++++++++++++++++++++++--
 tools/perf/util/probe-event.c          |  60 +---
 tools/perf/util/probe-finder.c         |  73 ++++-
 tools/perf/util/probe-finder.h         |   4 +
 8 files changed, 596 insertions(+), 107 deletions(-)

Masami Hiramatsu

Acked-by Tested-by

2015-04-14 07:04 UTC #16 lore raw

Quoted 6 lines · Arnaldo Carvalho de Melo

Em Mon, Apr 13, 2015 at 08:09:23PM -0300, Arnaldo Carvalho de Melo escreveu:
Quoted 5 lines
Em Tue, Apr 14, 2015 at 07:33:07AM +0900, Masami Hiramatsu escreveu:
Quoted 4 lines
Hi, Arnaldo,
Quoted 1 line
perf probe: Make --source avaiable when probe with lazy_line

Quoted 8 lines

Quoted 5 lines
Quoted 2 lines
No, could you pull Naohiro's patch?
I'd like to move get_real_path to probe_finder.c
OOps, yeah, you asked for that... Ingo, please ignore this pull request for now, thanks,
Ok, I did that and created a perf-core-for-mingo-2, Masami, please check that all is right, ok?

OK, I've built and tested it :)

Acked-by Masami Hiramatsu <[email protected]>

Tested-by Masami Hiramatsu <[email protected]>

Thank you!

Quoted 61 lines

- Arnaldo
The following changes since commit 066450be419fa48007a9f29e19828f2a86198754:
perf/x86/intel/pt: Clean up the control flow in pt_pmu_hw_init() (2015-04-12 11:21:15 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo-2
for you to fetch changes up to f19e80c640d58ddfd70f2454ee597f81ba966690:
perf probe: Fix segfault when probe with lazy_line to file (2015-04-13 20:12:21 -0300)
----------------------------------------------------------------
perf/core improvements and fixes:
New features:
- Analyze page allocator events also in 'perf kmem' (Namhyung Kim)
User visible fixes:
- Fix retprobe 'perf probe' handling when failing to find needed debuginfo (He Kuang)
- lazy_line probe fixes in 'perf probe' (Naohiro Aota, He Kuang)
Infrastructure:
- Record pfn instead of pointer to struct page in tracepoints (Namhyung Kim)
Signed-off-by Arnaldo Carvalho de Melo <[email protected]>
----------------------------------------------------------------
He Kuang (2):
perf probe: Set retprobe flag when probe in address-based alternative mode perf probe: Fix segfault when probe with lazy_line to file
Namhyung Kim (2):
tracing, mm: Record pfn instead of pointer to struct page perf kmem: Analyze page allocator events also
Naohiro Aota (1):
perf probe: Find compilation directory path for lazy matching
 include/trace/events/filemap.h         |   8 +-
 include/trace/events/kmem.h            |  42 +--
 include/trace/events/vmscan.h          |   8 +-
 tools/perf/Documentation/perf-kmem.txt |   8 +-
 tools/perf/builtin-kmem.c              | 500 +++++++++++++++++++++++++++++++--
 tools/perf/util/probe-event.c          |  60 +---
 tools/perf/util/probe-finder.c         |  73 ++++-
 tools/perf/util/probe-finder.h         |   4 +
 8 files changed, 596 insertions(+), 107 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Signature · 12 lines

Masami HIRAMATSU
Linux Technology Research Center, System Productivity Research Dept.
Center for Technology Innovation - Systems Engineering
Hitachi, Ltd., Research & Development Group
E-mail: [email protected]


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Arnaldo Carvalho de Melo

author maintainer

2015-04-14 12:17 UTC #17 lore raw

Em Tue, Apr 14, 2015 at 04:04:29PM +0900, Masami Hiramatsu escreveu:

Quoted 13 lines

Quoted 12 lines · Arnaldo Carvalho de Melo
Em Mon, Apr 13, 2015 at 08:09:23PM -0300, Arnaldo Carvalho de Melo escreveu:
Quoted 10 lines
Em Tue, Apr 14, 2015 at 07:33:07AM +0900, Masami Hiramatsu escreveu:
Quoted 6 lines
Hi, Arnaldo,
Quoted 1 line
perf probe: Make --source avaiable when probe with lazy_line
No, could you pull Naohiro's patch?
I'd like to move get_real_path to probe_finder.c
OOps, yeah, you asked for that... Ingo, please ignore this pull request for now, thanks,

Quoted 7 lines

Quoted 2 lines
Ok, I did that and created a perf-core-for-mingo-2, Masami, please check that all is right, ok?
OK, I've built and tested it :)
Acked-by Masami Hiramatsu <[email protected]>
Tested-by Masami Hiramatsu <[email protected]>

Thanks, and sorry for the slip up in getting the right patch as we agreed in that discussion,

Regards,

- Arnaldo

Quoted 48 lines

Thank you!
Quoted 46 lines
- Arnaldo
The following changes since commit 066450be419fa48007a9f29e19828f2a86198754:
perf/x86/intel/pt: Clean up the control flow in pt_pmu_hw_init() (2015-04-12 11:21:15 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo-2
for you to fetch changes up to f19e80c640d58ddfd70f2454ee597f81ba966690:
perf probe: Fix segfault when probe with lazy_line to file (2015-04-13 20:12:21 -0300)
----------------------------------------------------------------
perf/core improvements and fixes:
New features:
- Analyze page allocator events also in 'perf kmem' (Namhyung Kim)
User visible fixes:
- Fix retprobe 'perf probe' handling when failing to find needed debuginfo (He Kuang)
- lazy_line probe fixes in 'perf probe' (Naohiro Aota, He Kuang)
Infrastructure:
- Record pfn instead of pointer to struct page in tracepoints (Namhyung Kim)
Signed-off-by Arnaldo Carvalho de Melo <[email protected]>
----------------------------------------------------------------
He Kuang (2):
perf probe: Set retprobe flag when probe in address-based alternative mode perf probe: Fix segfault when probe with lazy_line to file
Namhyung Kim (2):
tracing, mm: Record pfn instead of pointer to struct page perf kmem: Analyze page allocator events also
Naohiro Aota (1):
perf probe: Find compilation directory path for lazy matching

Quoted 24 lines

Quoted 15 lines

 include/trace/events/filemap.h         |   8 +-
 include/trace/events/kmem.h            |  42 +--
 include/trace/events/vmscan.h          |   8 +-
 tools/perf/Documentation/perf-kmem.txt |   8 +-
 tools/perf/builtin-kmem.c              | 500 +++++++++++++++++++++++++++++++--
 tools/perf/util/probe-event.c          |  60 +---
 tools/perf/util/probe-finder.c         |  73 ++++-
 tools/perf/util/probe-finder.h         |   4 +
 8 files changed, 596 insertions(+), 107 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Signature · 5 lines

Masami HIRAMATSU
Linux Technology Research Center, System Productivity Research Dept.
Center for Technology Innovation - Systems Engineering
Hitachi, Ltd., Research & Development Group
E-mail: [email protected]

Ingo Molnar

2015-04-14 12:12 UTC #18 lore raw

In reply to Arnaldo Carvalho de Melo

Quoted 60 lines · Arnaldo Carvalho de Melo

Em Mon, Apr 13, 2015 at 08:09:23PM -0300, Arnaldo Carvalho de Melo escreveu:
Quoted 10 lines
Em Tue, Apr 14, 2015 at 07:33:07AM +0900, Masami Hiramatsu escreveu:
Quoted 6 lines
Hi, Arnaldo,
Quoted 1 line
perf probe: Make --source avaiable when probe with lazy_line
No, could you pull Naohiro's patch?
I'd like to move get_real_path to probe_finder.c
OOps, yeah, you asked for that... Ingo, please ignore this pull request for now, thanks,
Ok, I did that and created a perf-core-for-mingo-2, Masami, please check that all is right, ok?
- Arnaldo
The following changes since commit 066450be419fa48007a9f29e19828f2a86198754:
perf/x86/intel/pt: Clean up the control flow in pt_pmu_hw_init() (2015-04-12 11:21:15 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo-2
for you to fetch changes up to f19e80c640d58ddfd70f2454ee597f81ba966690:
perf probe: Fix segfault when probe with lazy_line to file (2015-04-13 20:12:21 -0300)
----------------------------------------------------------------
perf/core improvements and fixes:
New features:
- Analyze page allocator events also in 'perf kmem' (Namhyung Kim)
User visible fixes:
- Fix retprobe 'perf probe' handling when failing to find needed debuginfo (He Kuang)
- lazy_line probe fixes in 'perf probe' (Naohiro Aota, He Kuang)
Infrastructure:
- Record pfn instead of pointer to struct page in tracepoints (Namhyung Kim)
Signed-off-by Arnaldo Carvalho de Melo <[email protected]>
----------------------------------------------------------------
He Kuang (2):
perf probe: Set retprobe flag when probe in address-based alternative mode perf probe: Fix segfault when probe with lazy_line to file
Namhyung Kim (2):
tracing, mm: Record pfn instead of pointer to struct page perf kmem: Analyze page allocator events also
Naohiro Aota (1):
perf probe: Find compilation directory path for lazy matching

Quoted 9 lines

 include/trace/events/filemap.h         |   8 +-
 include/trace/events/kmem.h            |  42 +--
 include/trace/events/vmscan.h          |   8 +-
 tools/perf/Documentation/perf-kmem.txt |   8 +-
 tools/perf/builtin-kmem.c              | 500 +++++++++++++++++++++++++++++++--
 tools/perf/util/probe-event.c          |  60 +---
 tools/perf/util/probe-finder.c         |  73 ++++-
 tools/perf/util/probe-finder.h         |   4 +
 8 files changed, 596 insertions(+), 107 deletions(-)

Pulled, thanks a lot Arnaldo!

Ingo