From: Michal Hocko <mhocko@kernel.org>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: David Rientjes <rientjes@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [patch] mm, compaction: add vmstats for kcompactd work
Date: Thu, 8 Dec 2016 13:35:22 +0100 [thread overview]
Message-ID: <20161208123521.GB26535@dhcp22.suse.cz> (raw)
In-Reply-To: <f25f8fb9-47a9-ebd9-5a7a-95ca6dc324c9@suse.cz>
On Thu 08-12-16 09:04:12, Vlastimil Babka wrote:
> On 12/08/2016 02:50 AM, David Rientjes wrote:
> > A "compact_daemon_wake" vmstat exists that represents the number of times
> > kcompactd has woken up. This doesn't represent how much work it actually
> > did, though.
> >
> > It's useful to understand how much compaction work is being done by
> > kcompactd versus other methods such as direct compaction and explicitly
> > triggered per-node (or system) compaction.
> >
> > This adds two new vmstats: "compact_daemon_migrate_scanned" and
> > "compact_daemon_free_scanned" to represent the number of pages kcompactd
> > has scanned as part of its migration scanner and freeing scanner,
> > respectively.
> >
> > These values are still accounted for in the general
> > "compact_migrate_scanned" and "compact_free_scanned" for compatibility.
> >
> > It could be argued that explicitly triggered compaction could also be
> > tracked separately, and that could be added if others find it useful.
> >
> > Signed-off-by: David Rientjes <rientjes@google.com>
>
> A bit of downside is that stats are only updated when compaction finishes,
> but I guess it's acceptable.
Is this really unavoidable though? THe most common usecase for
/proc/vmstat is to collect data over time and perform some statistics to
see how things are going on. Doing this batched accounting will make
these kind of analysis less precise. Cannot we just do the accounting
the same way how we count the reclaim counters?
--
Michal Hocko
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:[~2016-12-08 12:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-08 1:50 David Rientjes
2016-12-08 8:04 ` Vlastimil Babka
2016-12-08 12:35 ` Michal Hocko [this message]
2016-12-12 22:20 ` David Rientjes
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=20161208123521.GB26535@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rientjes@google.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