From: David Rientjes <rientjes@google.com>
To: "Guilherme G. Piccoli" <kernel@gpiccoli.net>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"Guilherme G. Piccoli" <gpiccoli@canonical.com>,
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: Fri, 8 May 2020 11:31:12 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.22.394.2005081129100.236131@chino.kir.corp.google.com> (raw)
In-Reply-To: <CALJn8nNDqWwanhmutCiP-WBLN1eSg2URrG2j5R4kzgHTYObs7Q@mail.gmail.com>
On Thu, 7 May 2020, Guilherme G. Piccoli wrote:
> Well...you can think that the problem we are trying to solve was more
> like...admin forgot if they triggered or not the compaction hehe
> So, counting on the user to keep track of it is what I'd like to
> avoid. And thinking about drop_caches (that have an indication when
> triggered) makes me think this indeed does make sense for compaction
> too.
> Cheers,
>
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.
next prev parent reply other threads:[~2020-05-08 18:31 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 [this message]
2020-05-08 19:01 ` Guilherme Piccoli
2020-05-11 1:24 ` David Rientjes
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.2005081129100.236131@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