linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Charan Teja Kalla <charante@codeaurora.org>
To: "Chu,Kaiping" <chukaiping@baidu.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"mcgrof@kernel.org" <mcgrof@kernel.org>,
	"keescook@chromium.org" <keescook@chromium.org>,
	"yzaikin@google.com" <yzaikin@google.com>,
	"vbabka@suse.cz" <vbabka@suse.cz>,
	"nigupta@nvidia.com" <nigupta@nvidia.com>,
	"bhe@redhat.com" <bhe@redhat.com>,
	"mateusznosek0@gmail.com" <mateusznosek0@gmail.com>,
	"sh_def@163.com" <sh_def@163.com>,
	"iamjoonsoo.kim@lge.com" <iamjoonsoo.kim@lge.com>,
	"vinmenon@codeaurora.org" <vinmenon@codeaurora.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: 答复: [PATCH V2] mm: compaction: support triggering of proactive compaction by user
Date: Wed, 19 May 2021 15:49:39 +0530	[thread overview]
Message-ID: <e17fb3b8-2737-0d4c-eede-093a2aa2ed8b@codeaurora.org> (raw)
In-Reply-To: <79279be3573542dea0266f8e9d4d5368@baidu.com>

Thanks Kaiping for your review comments!!

On 5/19/2021 7:11 AM, Chu,Kaiping wrote:
>> This triggering of proactive compaction is done on a write to
>> sysctl.compaction_proactiveness by user.
> If you want to trigger compaction from userspace, you can use " echo 1 > /proc/sys/vm/compact_memory", there is no need to be so complex.

1) compact_memory is intended for debug interface. And moreover we can't
issue the compaction in some controlled manner as write to this node
triggers the full node compaction. This patch aims at users who want to
do the compaction in some controlled manner from user space. Example
user is app launcher preparing the system before launching a memory
hungry app.

2) Also, with the current implementation of proactive compaction, say
user sets the sysctl.compaction_proactiveness, the values can have
effect only in the next HPAGE_FRAG_CHECK_INTERVAL_MSEC(500msec), IOW,
the proactive compaction can run with the new settings only after
500msec which can make the user to wait for 500msec after setting a
value in the compaction_proactiveness to think that the value written is
came into effectiveness. Say user want to launch a gaming application
which has higher memory requirements and its launch time is proportional
to the available higher order pages. So, what he can do to get the
larger number of pages is set the compaction_proactivness to higher
value, continue launching the application and once finishes can set the
proactivness to original value. But with the current implementation the
value set may not come into effectiveness at all because of the 500msec
delay.Thus,the patch also handles the scenario of requiring the
proactive compaction to run immediately once user sets the
'compaction_proactiveness'.

May be I need to update the commit log even more clear about why can't
we use the 'compact_memory' and requirements to need to run the
proactive compaction immediately once user changes the
compaction_proactivness.

> 

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum, a Linux Foundation Collaborative Project

  reply	other threads:[~2021-05-19 10:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-18 13:37 [PATCH V2] mm: compaction: support triggering of proactive compaction by user Charan Teja Reddy
2021-05-19  1:41 ` 答复: " Chu,Kaiping
2021-05-19 10:19   ` Charan Teja Kalla [this message]
2021-05-25 14:20 ` Charan Teja Kalla
2021-05-25 20:35 ` Nitin Gupta
2021-05-27  9:28   ` Charan Teja Kalla
2021-05-27 23:52     ` Nitin Gupta
2021-05-29  2:57       ` Charan Teja Kalla
2021-05-28 15:19 ` Vlastimil Babka
2021-05-28 17:02   ` Charan Teja Kalla

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=e17fb3b8-2737-0d4c-eede-093a2aa2ed8b@codeaurora.org \
    --to=charante@codeaurora.org \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=chukaiping@baidu.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=keescook@chromium.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mateusznosek0@gmail.com \
    --cc=mcgrof@kernel.org \
    --cc=nigupta@nvidia.com \
    --cc=sh_def@163.com \
    --cc=vbabka@suse.cz \
    --cc=vinmenon@codeaurora.org \
    --cc=yzaikin@google.com \
    /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).