linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Michal Hocko <mhocko@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Minchan Kim <minchan@kernel.org>,
	Sasha Levin <sasha.levin@oracle.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Mel Gorman <mgorman@suse.de>, Hugh Dickins <hughd@google.com>
Subject: Re: [PATCH v3 12/14] mm, page_owner: track and print last migrate reason
Date: Thu, 7 Jan 2016 14:17:47 +0100	[thread overview]
Message-ID: <568E657B.9040306@suse.cz> (raw)
In-Reply-To: <20160107105404.GJ27868@dhcp22.suse.cz>

On 01/07/2016 11:54 AM, Michal Hocko wrote:
> On Fri 18-12-15 10:03:24, Vlastimil Babka wrote:
>> During migration, page_owner info is now copied with the rest of the page, so
>> the stacktrace leading to free page allocation during migration is overwritten.
>> For debugging purposes, it might be however useful to know that the page has
>> been migrated since its initial allocation. This might happen many times during
>> the lifetime for different reasons and fully tracking this, especially with
>> stacktraces would incur extra memory costs. As a compromise, store and print
>> the migrate_reason of the last migration that occurred to the page. This is
>> enough to distinguish compaction, numa balancing etc.
>
> So you know that the page has been migrated because of compaction the
> last time. You do not know anything about the previous migrations
> though. How would you use that information during debugging? Wouldn't it

The assumption is that if a migration does something bad, chances are it 
will manifest before another migration happens. I.e. the last migration 
is probably more related to the bug (e.g. catched by VM_BUG_ON_PAGE()) 
than the previous ones. Statistically if trinity sees more errors 
implying compaction than numa balancing, we should look for bugs in 
compaction, etc.

> be sufficient to know that the page has been migrated (or count how many
> times) instead? That would lead to less code and it might be sufficient
> for practical use.

Yeah it's hard to predict how useful/sufficient this patch would be. The 
fact that migration happened should be definitely noted. How many times 
is not that useful IMHO. Migrate reason seemed appropriate and useful 
enough and we already distinguish them for tracepoints.


  reply	other threads:[~2016-01-07 13:17 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-18  9:03 [PATCH v3 00/14] mm flags in printk, page_owner improvements for debugging Vlastimil Babka
2015-12-18  9:03 ` [PATCH v3 01/14] tracepoints: move trace_print_flags definitions to tracepoint-defs.h Vlastimil Babka
2015-12-18  9:03 ` [PATCH v3 02/14] mm, tracing: make show_gfp_flags() up to date Vlastimil Babka
2016-01-07  9:29   ` Michal Hocko
2015-12-18  9:03 ` [PATCH v3 03/14] tools, perf: make gfp_compact_table " Vlastimil Babka
2015-12-18  9:03 ` [PATCH v3 04/14] mm, tracing: unify mm flags handling in tracepoints and printk Vlastimil Babka
2016-01-07  9:46   ` Michal Hocko
2015-12-18  9:03 ` [PATCH v3 05/14] mm, printk: introduce new format string for flags Vlastimil Babka
2016-01-07  9:53   ` Michal Hocko
2015-12-18  9:03 ` [PATCH v3 06/14] mm, debug: replace dump_flags() with the new printk formats Vlastimil Babka
2016-01-07  9:57   ` Michal Hocko
2015-12-18  9:03 ` [PATCH v3 07/14] mm, page_alloc: print symbolic gfp_flags on allocation failure Vlastimil Babka
2015-12-18  9:03 ` [PATCH v3 08/14] mm, oom: print symbolic gfp_flags in oom warning Vlastimil Babka
2015-12-18  9:03 ` [PATCH v3 09/14] mm, page_owner: print migratetype of page and pageblock, symbolic flags Vlastimil Babka
2016-01-07 10:06   ` Michal Hocko
2015-12-18  9:03 ` [PATCH v3 10/14] mm, page_owner: convert page_owner_inited to static key Vlastimil Babka
2016-01-07 10:21   ` Michal Hocko
2015-12-18  9:03 ` [PATCH v3 11/14] mm, page_owner: copy page owner info during migration Vlastimil Babka
2016-01-07 10:44   ` Michal Hocko
2015-12-18  9:03 ` [PATCH v3 12/14] mm, page_owner: track and print last migrate reason Vlastimil Babka
2016-01-07 10:54   ` Michal Hocko
2016-01-07 13:17     ` Vlastimil Babka [this message]
2015-12-18  9:03 ` [PATCH v3 13/14] mm, page_owner: dump page owner info from dump_page() Vlastimil Babka
2015-12-18  9:03 ` [PATCH v3 14/14] mm, debug: move bad flags printing to bad_page() Vlastimil Babka
2016-01-07 13:10   ` Michal Hocko

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=568E657B.9040306@suse.cz \
    --to=vbabka@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=hughd@google.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mhocko@kernel.org \
    --cc=minchan@kernel.org \
    --cc=sasha.levin@oracle.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: 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;
as well as URLs for NNTP newsgroup(s).