linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@suse.de>
To: Minchan Kim <minchan@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] mm: fix pgalloc_stall on unpopulated zone
Date: Wed, 13 Jul 2016 10:25:04 +0100	[thread overview]
Message-ID: <20160713092504.GJ11400@suse.de> (raw)
In-Reply-To: <1468376653-26561-1-git-send-email-minchan@kernel.org>

On Wed, Jul 13, 2016 at 11:24:13AM +0900, Minchan Kim wrote:
> If we use sc->reclaim_idx for accounting pgstall, it can increase
> the count on unpopulated zone, for example, movable zone(but
> my system doesn't have movable zone) if allocation request were
> GFP_HIGHUSER_MOVABLE. It doesn't make no sense.
> 

I wanted to track the highest zone allowed by each allocation regardless
of what the zone population state was. Otherwise, consider the following
on a NUMA system

1. An allocation request arrives for GFP_HIGHUSER_MOVABLE that stalls
2. System has two nodes, node 0 with ZONE_NORMAL, node 1 with ZONE_HIGHMEM
3. If the allocating process is on node 0, the stall is accounted on ZONE_NORMAL
4. If the allocatinn process is on node 1, the stall is accounted on ZONE_HIGHMEM

Multiple runs of the same workload on the same machine will see stall
statistics on different zones and renders the stat useless. This is
difficult to analyse because stalls accounted for on ZONE_NORMAL may or
may not be zone-constrained allocations.

The patch means that the vmstat accounting and tracepoint data is also
out of sync. One thing I wanted to be able to do was

1. Observe that there are alloc stalls on DMA32 or some other low zone
2. Activate mm_vmscan_direct_reclaim_begin, filter on classzone_idx ==
   DMA32 and identify the source of the lowmem allocations

If your patch is applied, I cannot depend on the stall stats any more
and the tracepoint is required to determine if there really any
zone-contrained allocations. It can be *inferred* from the skip stats
but only if such skips occurred and that is not guaranteed.

-- 
Mel Gorman
SUSE Labs

  reply	other threads:[~2016-07-13  9:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-13  2:24 [PATCH] mm: fix pgalloc_stall on unpopulated zone Minchan Kim
2016-07-13  9:25 ` Mel Gorman [this message]
2016-07-14  1:11   ` Minchan Kim
2016-07-14  8:51     ` Mel Gorman
2016-07-14  8:58       ` Minchan Kim

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=20160713092504.GJ11400@suse.de \
    --to=mgorman@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    /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).