From: Mel Gorman <mgorman@suse.de>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Rik van Riel <riel@redhat.com>
Subject: Re: [PATCH] mm: compaction: Trace compaction begin and end
Date: Thu, 5 Dec 2013 09:05:44 +0000 [thread overview]
Message-ID: <20131205090544.GF11295@suse.de> (raw)
In-Reply-To: <529F418D.3070108@suse.cz>
On Wed, Dec 04, 2013 at 03:51:57PM +0100, Vlastimil Babka wrote:
> On 12/04/2013 03:30 PM, Mel Gorman wrote:
> >This patch adds two tracepoints for compaction begin and end of a zone. Using
> >this it is possible to calculate how much time a workload is spending
> >within compaction and potentially debug problems related to cached pfns
> >for scanning.
>
> I guess for debugging pfns it would be also useful to print their
> values also in mm_compaction_end.
>
What additional information would we get from it and what new
conclusions could we draw? We could guess how much work the
scanners did but the trace_mm_compaction_isolate_freepages and
trace_mm_compaction_isolate_migratepages tracepoints already accurately
tell us that. The scanner PFNs alone do not tell us if the cached pfns
were updated and even if it did, the information can be changed by
parallel resets so it would be hard to draw reasonable conclusions from
the information. We could guess where compaction hotspots might be but
without the skip information, we could not detect it accurately. If we
wanted to detect that accurately, the mm_compaction_isolate* tracepoints
would be the one to update.
I was primarily concerned about compaction time so I might be looking
at this the wrong way but it feels like having the PFNs at the end of a
compaction cycle would be of marginal benefit.
> >In combination with the direct reclaim and slab trace points
> >it should be possible to estimate most allocation-related overhead for
> >a workload.
> >
> >Signed-off-by: Mel Gorman <mgorman@suse.de>
> >---
> > include/trace/events/compaction.h | 42 +++++++++++++++++++++++++++++++++++++++
> > mm/compaction.c | 4 ++++
> > 2 files changed, 46 insertions(+)
> >
> >diff --git a/include/trace/events/compaction.h b/include/trace/events/compaction.h
> >index fde1b3e..f4e115a 100644
> >--- a/include/trace/events/compaction.h
> >+++ b/include/trace/events/compaction.h
> >@@ -67,6 +67,48 @@ TRACE_EVENT(mm_compaction_migratepages,
> > __entry->nr_failed)
> > );
> >
> >+TRACE_EVENT(mm_compaction_begin,
> >+ TP_PROTO(unsigned long zone_start, unsigned long migrate_start,
> >+ unsigned long zone_end, unsigned long free_start),
> >+
> >+ TP_ARGS(zone_start, migrate_start, zone_end, free_start),
>
> IMHO a better order would be:
> zone_start, migrate_start, free_start, zone_end
> (well especially in the TP_printk part anyway).
>
Ok, that would put them in PFN order which may be easier to visualise.
I'll post a V2 with that change at least.
--
Mel Gorman
SUSE Labs
--
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 prev parent reply other threads:[~2013-12-05 9:05 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-25 14:26 [RFC PATCH 0/5] Memory compaction efficiency improvements Vlastimil Babka
2013-11-25 14:26 ` [PATCH 1/5] mm: compaction: encapsulate defer reset logic Vlastimil Babka
2013-11-25 22:08 ` Rik van Riel
2013-11-26 10:16 ` Mel Gorman
2013-11-25 14:26 ` [PATCH 2/5] mm: compaction: reset cached scanner pfn's before reading them Vlastimil Babka
2013-11-26 10:23 ` Mel Gorman
2013-11-26 13:16 ` Rik van Riel
2013-11-25 14:26 ` [PATCH 3/5] mm: compaction: detect when scanners meet in isolate_freepages Vlastimil Babka
2013-11-26 10:45 ` Mel Gorman
2013-11-26 16:44 ` Vlastimil Babka
2013-11-25 14:26 ` [PATCH 4/5] mm: compaction: do not mark unmovable pageblocks as skipped in async compaction Vlastimil Babka
2013-11-26 10:58 ` Mel Gorman
2013-11-25 14:26 ` [PATCH 5/5] mm: compaction: reset scanner positions immediately when they meet Vlastimil Babka
2013-11-26 11:03 ` Mel Gorman
2013-12-04 14:30 ` [PATCH] mm: compaction: Trace compaction begin and end Mel Gorman
2013-12-04 14:51 ` Vlastimil Babka
2013-12-05 9:05 ` Mel Gorman [this message]
2013-12-06 9:50 ` Vlastimil Babka
2013-12-05 9:07 ` [PATCH] mm: compaction: Trace compaction begin and end v2 Mel Gorman
2013-12-06 9:50 ` Vlastimil Babka
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=20131205090544.GF11295@suse.de \
--to=mgorman@suse.de \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=riel@redhat.com \
--cc=vbabka@suse.cz \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox