This patch adds a trace event for munmap which will record the starting
address of the unmapped area and the length of the umapped area. This
event will be used for modeling memory usage.
Signed-of-by: Eric B Munson <[email protected]>
---
include/trace/events/mm.h | 30 ++++++++++++++++++++++++++++++
mm/mmap.c | 5 +++++
2 files changed, 35 insertions(+), 0 deletions(-)
create mode 100644 include/trace/events/mm.h
diff --git a/include/trace/events/mm.h b/include/trace/events/mm.h
new file mode 100644
index 0000000..c3a3857
--- /dev/null
+++ b/include/trace/events/mm.h
@@ -0,0 +1,30 @@
+#if !defined(_TRACE_MM_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_MM_H_
+
+#include <linux/tracepoint.h>
+
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM mm
+
+TRACE_EVENT(munmap,
+ TP_PROTO(unsigned long start, size_t len),
+
+ TP_ARGS(start, len),
+
+ TP_STRUCT__entry(
+ __field(unsigned long, start)
+ __field(size_t, len)
+ ),
+
+ TP_fast_assign(
+ __entry->start = start;
+ __entry->len = len;
+ ),
+
+ TP_printk("unmapping %u bytes at %lu\n", __entry->len, __entry->start)
+);
+
+#endif /* _TRACE_MM_H_ */
+
+/* This part must be outside protection */
+#include <trace/define_trace.h>
diff --git a/mm/mmap.c b/mm/mmap.c
index 456ec6f..0775a30 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -29,6 +29,9 @@
#include <linux/mmu_notifier.h>
#include <linux/perf_event.h>
+#define CREATE_TRACE_POINTS
+#include <trace/events/mm.h>
+
#include <asm/uaccess.h>
#include <asm/cacheflush.h>
#include <asm/tlb.h>
@@ -2079,6 +2082,8 @@ int do_munmap(struct mm_struct *mm, unsigned long start, size_t len)
}
}
+ trace_munmap(start, len);
+
/*
* Remove the vma's, and unmap the actual pages
*/
--
1.7.0.4
On 07/08/2010 10:05 AM, Eric B Munson wrote:
> This patch adds a trace event for munmap which will record the starting
> address of the unmapped area and the length of the umapped area. This
> event will be used for modeling memory usage.
Sounds like a useful trace point to me.
> Signed-of-by: Eric B Munson<[email protected]>
Reviewed-by: Rik van Riel <[email protected]>
--
All rights reversed
On Thu, 2010-07-08 at 15:05 +0100, Eric B Munson wrote:
> This patch adds a trace event for munmap which will record the starting
> address of the unmapped area and the length of the umapped area. This
> event will be used for modeling memory usage.
Does it make sense to couple this with a mmap()/mremap()/brk()
tracepoint?
On Thu, 08 Jul 2010, Peter Zijlstra wrote:
> On Thu, 2010-07-08 at 15:05 +0100, Eric B Munson wrote:
> > This patch adds a trace event for munmap which will record the starting
> > address of the unmapped area and the length of the umapped area. This
> > event will be used for modeling memory usage.
>
> Does it make sense to couple this with a mmap()/mremap()/brk()
> tracepoint?
>
We were using the mmap information collected by perf, but I think
those might also be useful so I will send a followup patch to add
them.
--
Eric B Munson
IBM Linux Technology Center
[email protected]
On Thu, Jul 08, 2010 at 03:44:07PM +0100, Eric B Munson wrote:
> On Thu, 08 Jul 2010, Peter Zijlstra wrote:
>
> > On Thu, 2010-07-08 at 15:05 +0100, Eric B Munson wrote:
> > > This patch adds a trace event for munmap which will record the starting
> > > address of the unmapped area and the length of the umapped area. This
> > > event will be used for modeling memory usage.
> >
> > Does it make sense to couple this with a mmap()/mremap()/brk()
> > tracepoint?
> >
>
> We were using the mmap information collected by perf, but I think
> those might also be useful so I will send a followup patch to add
> them.
What kind of infrastructure is perf using for recording
mmap()/mremap()/brk() information?
On Thu, 2010-07-08 at 13:35 -0400, Christoph Hellwig wrote:
> What kind of infrastructure is perf using for recording
> mmap()/mremap()/brk() information?
A direct hook into mmap_region(), see perf_event_mmap().
We used to only track VM_EXEC regions, but these days we can also track
data regions (although it wouldn't track mremap and brk I think).
We need the VM_EXEC maps to make sense of the instruction pointer
samples.
Eric recently added support for !VM_EXEC mmap() in order to interpret
linear addresses provided by things like the software pagefault events
and certain powerpc hardware events.
On Thu, Jul 08, 2010 at 07:48:08PM +0200, Peter Zijlstra wrote:
> On Thu, 2010-07-08 at 13:35 -0400, Christoph Hellwig wrote:
>
> > What kind of infrastructure is perf using for recording
> > mmap()/mremap()/brk() information?
>
> A direct hook into mmap_region(), see perf_event_mmap().
>
> We used to only track VM_EXEC regions, but these days we can also track
> data regions (although it wouldn't track mremap and brk I think).
>
> We need the VM_EXEC maps to make sense of the instruction pointer
> samples.
>
> Eric recently added support for !VM_EXEC mmap() in order to interpret
> linear addresses provided by things like the software pagefault events
> and certain powerpc hardware events.
Maybe the user reporting should use trace points everywhere, leaving
the direct hook just for the executable tracking?