From: Mel Gorman <mel@csn.ul.ie> To: Larry Woodman <lwoodman@redhat.com>, Andrew Morton <akpm@linux-foundation.org> Cc: riel@redhat.com, Ingo Molnar <mingo@elte.hu>, Peter Zijlstra <peterz@infradead.org>, LKML <linux-kernel@vger.kernel.org>, linux-mm@kvack.org, Mel Gorman <mel@csn.ul.ie> Subject: [PATCH 0/4] Add some trace events for the page allocator v3 Date: Tue, 4 Aug 2009 19:12:22 +0100 [thread overview] Message-ID: <1249409546-6343-1-git-send-email-mel@csn.ul.ie> (raw) Changelog since V2 o Added Ack-ed By's from Rik o Only call trace_mm_page_free_direct when page count reaches zero o Rebase to 2.6.31-rc5 Changelog since V1 o Fix minor formatting error for the __rmqueue event o Add event for __pagevec_free o Bring naming more in line with Larry Woodman's tracing patch o Add an example post-processing script for the trace events This is V3 of a patchset to add some trace points for the page allocator. This version adds some ACKs, drops the RFC from the headline and fixes one issue where trace_mm_page_free_direct triggered more than it should. The following four patches add some trace events for the page allocator under the heading of kmem. Patch 1 adds events for plain old allocate and freeing of pages Patch 2 gives information useful for analysing fragmentation avoidance Patch 3 tracks pages going to and from the buddy lists as an indirect indication of zone lock hotness Patch 4 adds a post-processing script that aggegates the events to give a higher-level view The first one could be used as an indicator as to whether the workload was heavily dependant on the page allocator or not. You can make a guess based on vmstat but you can't get a per-process breakdown. Depending on the call path, the call_site for page allocation may be __get_free_pages() instead of a useful callsite. Instead of passing down a return address similar to slab debugging, the user should enable the stacktrace and seg-addr options to get a proper stack trace. The second patch would mainly be useful for users of hugepages and particularly dynamic hugepage pool resizing as it could be used to tune min_free_kbytes to a level that fragmentation was rarely a problem. My main concern is that maybe I'm trying to jam too much into the TP_printk that could be extrapolated after the fact if you were familiar with the implementation. I couldn't determine if it was best to hold the hand of the administrator even if it cost more to figure it out. The third patch is trickier to draw conclusions from but high activity on those events could explain why there were a large number of cache misses on a page-allocator-intensive workload. The coalescing and splitting of buddies involves a lot of writing of page metadata and cache line bounces not to mention the acquisition of an interrupt-safe lock necessary to enter this path. The fourth patch parses the trace buffer to draw a higher-level picture of what is going on broken down on a per-process basis. .../postprocess/trace-pagealloc-postprocess.pl | 131 ++++++++++++++ include/trace/events/kmem.h | 184 ++++++++++++++++++++ mm/page_alloc.c | 14 ++- 3 files changed, 328 insertions(+), 1 deletions(-) create mode 100755 Documentation/trace/postprocess/trace-pagealloc-postprocess.pl
WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mel@csn.ul.ie> To: Larry Woodman <lwoodman@redhat.com>, Andrew Morton <akpm@linux-foundation.org> Cc: riel@redhat.com, Ingo Molnar <mingo@elte.hu>, Peter Zijlstra <peterz@infradead.org>, LKML <linux-kernel@vger.kernel.org>, linux-mm@kvack.org, Mel Gorman <mel@csn.ul.ie> Subject: [PATCH 0/4] Add some trace events for the page allocator v3 Date: Tue, 4 Aug 2009 19:12:22 +0100 [thread overview] Message-ID: <1249409546-6343-1-git-send-email-mel@csn.ul.ie> (raw) Changelog since V2 o Added Ack-ed By's from Rik o Only call trace_mm_page_free_direct when page count reaches zero o Rebase to 2.6.31-rc5 Changelog since V1 o Fix minor formatting error for the __rmqueue event o Add event for __pagevec_free o Bring naming more in line with Larry Woodman's tracing patch o Add an example post-processing script for the trace events This is V3 of a patchset to add some trace points for the page allocator. This version adds some ACKs, drops the RFC from the headline and fixes one issue where trace_mm_page_free_direct triggered more than it should. The following four patches add some trace events for the page allocator under the heading of kmem. Patch 1 adds events for plain old allocate and freeing of pages Patch 2 gives information useful for analysing fragmentation avoidance Patch 3 tracks pages going to and from the buddy lists as an indirect indication of zone lock hotness Patch 4 adds a post-processing script that aggegates the events to give a higher-level view The first one could be used as an indicator as to whether the workload was heavily dependant on the page allocator or not. You can make a guess based on vmstat but you can't get a per-process breakdown. Depending on the call path, the call_site for page allocation may be __get_free_pages() instead of a useful callsite. Instead of passing down a return address similar to slab debugging, the user should enable the stacktrace and seg-addr options to get a proper stack trace. The second patch would mainly be useful for users of hugepages and particularly dynamic hugepage pool resizing as it could be used to tune min_free_kbytes to a level that fragmentation was rarely a problem. My main concern is that maybe I'm trying to jam too much into the TP_printk that could be extrapolated after the fact if you were familiar with the implementation. I couldn't determine if it was best to hold the hand of the administrator even if it cost more to figure it out. The third patch is trickier to draw conclusions from but high activity on those events could explain why there were a large number of cache misses on a page-allocator-intensive workload. The coalescing and splitting of buddies involves a lot of writing of page metadata and cache line bounces not to mention the acquisition of an interrupt-safe lock necessary to enter this path. The fourth patch parses the trace buffer to draw a higher-level picture of what is going on broken down on a per-process basis. .../postprocess/trace-pagealloc-postprocess.pl | 131 ++++++++++++++ include/trace/events/kmem.h | 184 ++++++++++++++++++++ mm/page_alloc.c | 14 ++- 3 files changed, 328 insertions(+), 1 deletions(-) create mode 100755 Documentation/trace/postprocess/trace-pagealloc-postprocess.pl -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next reply other threads:[~2009-08-04 18:13 UTC|newest] Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-08-04 18:12 Mel Gorman [this message] 2009-08-04 18:12 ` [PATCH 0/4] Add some trace events for the page allocator v3 Mel Gorman 2009-08-04 18:12 ` [PATCH 1/4] tracing, page-allocator: Add trace events for page allocation and page freeing Mel Gorman 2009-08-04 18:12 ` Mel Gorman 2009-08-05 9:13 ` KOSAKI Motohiro 2009-08-05 9:13 ` KOSAKI Motohiro 2009-08-05 9:40 ` Mel Gorman 2009-08-05 9:40 ` Mel Gorman 2009-08-07 1:17 ` KOSAKI Motohiro 2009-08-07 1:17 ` KOSAKI Motohiro 2009-08-07 17:31 ` Mel Gorman 2009-08-07 17:31 ` Mel Gorman 2009-08-08 5:44 ` KOSAKI Motohiro 2009-08-08 5:44 ` KOSAKI Motohiro 2009-08-04 18:12 ` [PATCH 2/4] tracing, mm: Add trace events for anti-fragmentation falling back to other migratetypes Mel Gorman 2009-08-04 18:12 ` Mel Gorman 2009-08-05 9:26 ` KOSAKI Motohiro 2009-08-05 9:26 ` KOSAKI Motohiro 2009-08-04 18:12 ` [PATCH 3/4] tracing, page-allocator: Add trace event for page traffic related to the buddy lists Mel Gorman 2009-08-04 18:12 ` Mel Gorman 2009-08-05 9:24 ` KOSAKI Motohiro 2009-08-05 9:24 ` KOSAKI Motohiro 2009-08-05 9:43 ` Mel Gorman 2009-08-05 9:43 ` Mel Gorman 2009-08-07 1:03 ` KOSAKI Motohiro 2009-08-07 1:03 ` KOSAKI Motohiro 2009-08-04 18:12 ` [PATCH 4/4] tracing, page-allocator: Add a postprocessing script for page-allocator-related ftrace events Mel Gorman 2009-08-04 18:12 ` Mel Gorman 2009-08-04 18:22 ` Andrew Morton 2009-08-04 18:22 ` Andrew Morton 2009-08-04 18:27 ` Rik van Riel 2009-08-04 18:27 ` Rik van Riel 2009-08-04 19:13 ` Andrew Morton 2009-08-04 19:13 ` Andrew Morton 2009-08-04 20:48 ` Mel Gorman 2009-08-04 20:48 ` Mel Gorman 2009-08-05 7:41 ` Ingo Molnar 2009-08-05 7:41 ` Ingo Molnar 2009-08-05 9:07 ` Mel Gorman 2009-08-05 9:07 ` Mel Gorman 2009-08-05 9:16 ` Ingo Molnar 2009-08-05 9:16 ` Ingo Molnar 2009-08-05 10:27 ` Johannes Weiner 2009-08-05 10:27 ` Johannes Weiner 2009-08-06 15:48 ` Mel Gorman 2009-08-06 15:48 ` Mel Gorman 2009-08-05 14:53 ` Larry Woodman 2009-08-05 14:53 ` Larry Woodman 2009-08-06 15:54 ` Mel Gorman 2009-08-06 15:54 ` Mel Gorman 2009-08-04 19:57 ` Ingo Molnar 2009-08-04 19:57 ` Ingo Molnar 2009-08-04 20:18 ` Andrew Morton 2009-08-04 20:18 ` Andrew Morton 2009-08-04 20:35 ` Ingo Molnar 2009-08-04 20:35 ` Ingo Molnar 2009-08-04 20:53 ` Andrew Morton 2009-08-04 20:53 ` Andrew Morton 2009-08-05 7:53 ` Ingo Molnar 2009-08-05 7:53 ` Ingo Molnar 2009-08-05 13:04 ` Peter Zijlstra 2009-08-05 13:04 ` Peter Zijlstra 2009-08-05 15:07 ` Valdis.Kletnieks 2009-08-05 14:53 ` Valdis.Kletnieks 2009-08-05 18:53 ` perf: "Longum est iter per praecepta, breve et efficax per exempla" Carlos R. Mafra 2009-08-06 7:08 ` Pekka Enberg 2009-08-06 7:35 ` Ingo Molnar 2009-08-06 8:38 ` Carlos R. Mafra 2009-08-06 8:32 ` Carlos R. Mafra 2009-08-06 9:10 ` Ingo Molnar 2009-08-08 12:37 ` [tip:perfcounters/urgent] " tip-bot for Carlos R. Mafra 2009-08-09 11:11 ` [tip:perfcounters/core] " tip-bot for Carlos R. Mafra 2009-08-06 15:50 ` [PATCH 4/4] tracing, page-allocator: Add a postprocessing script for page-allocator-related ftrace events Mel Gorman 2009-08-06 15:50 ` Mel Gorman 2009-08-05 3:07 ` KOSAKI Motohiro 2009-08-05 3:07 ` KOSAKI Motohiro
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1249409546-6343-1-git-send-email-mel@csn.ul.ie \ --to=mel@csn.ul.ie \ --cc=akpm@linux-foundation.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=lwoodman@redhat.com \ --cc=mingo@elte.hu \ --cc=peterz@infradead.org \ --cc=riel@redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.