From: David Rientjes <rientjes@google.com>
To: Guilherme Piccoli <gpiccoli@canonical.com>
Cc: "Guilherme G. Piccoli" <kernel@gpiccoli.net>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Gavin Guo <gavin.guo@canonical.com>,
Mel Gorman <mgorman@techsingularity.net>
Subject: Re: [PATCH] mm, compaction: Indicate when compaction is manually triggered by sysctl
Date: Sun, 10 May 2020 18:24:58 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.22.394.2005101821160.172131@chino.kir.corp.google.com> (raw)
In-Reply-To: <CAHD1Q_wF6Mzf5JipXGZKvn2YDR+FQ6ePuKOe-1W-t_VapxMCxg@mail.gmail.com>
On Fri, 8 May 2020, Guilherme Piccoli wrote:
> On Fri, May 8, 2020 at 3:31 PM David Rientjes <rientjes@google.com> wrote:
> > It doesn't make sense because it's only being done here for the entire
> > system, there are also per-node sysfs triggers so you could do something
> > like iterate over the nodemask of all nodes with memory and trigger
> > compaction manually and then nothing is emitted to the kernel log.
> >
> > There is new statsfs support that Red Hat is proposing that can be used
> > for things like this. It currently only supports KVM statistics but
> > adding MM statistics is something that would be a natural extension and
> > avoids polluting both the kernel log and /proc/vmstat.
>
> Thanks for the review. Is this what you're talking about [0] ? Very interesting!
>
Exactly.
> Also, I agree about the per-node compaction, it's a good point. But at
> the same time, having the information on the number of manual
> compaction triggered is interesting, at least for some users. What if
> we add that as a per-node stat in zoneinfo?
>
The kernel log is not preferred for this (or drop_caches, really) because
the amount of info can causing important information to be lost. We don't
really gain anything by printing that someone manually triggered
compaction; they could just write to the kernel log themselves if they
really wanted to. The reverse is not true: we can't suppress your kernel
message with this patch.
Instead, a statsfs-like approach could be used to indicate when this has
happened and there is no chance of losing events because it got scrolled
off the kernel log. It has the added benefit of not requiring the entire
log to be parsed for such events.
next prev parent reply other threads:[~2020-05-11 1:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-07 21:59 Guilherme G. Piccoli
2020-05-07 23:04 ` Andrew Morton
2020-05-08 2:14 ` Guilherme G. Piccoli
2020-05-08 18:31 ` David Rientjes
2020-05-08 19:01 ` Guilherme Piccoli
2020-05-11 1:24 ` David Rientjes [this message]
2020-05-11 11:26 ` Guilherme Piccoli
2020-05-18 7:06 ` peter enderborg
2020-05-18 12:14 ` Guilherme Piccoli
2020-05-18 12:54 ` Enderborg, Peter
2020-05-18 13:50 ` Guilherme Piccoli
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=alpine.DEB.2.22.394.2005101821160.172131@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=akpm@linux-foundation.org \
--cc=gavin.guo@canonical.com \
--cc=gpiccoli@canonical.com \
--cc=kernel@gpiccoli.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
/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