linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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.


  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