[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e17fb3b8-2737-0d4c-eede-093a2aa2ed8b@codeaurora.org>
Date: Wed, 19 May 2021 15:49:39 +0530
From: Charan Teja Kalla <charante@...eaurora.org>
To: "Chu,Kaiping" <chukaiping@...du.com>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"mcgrof@...nel.org" <mcgrof@...nel.org>,
"keescook@...omium.org" <keescook@...omium.org>,
"yzaikin@...gle.com" <yzaikin@...gle.com>,
"vbabka@...e.cz" <vbabka@...e.cz>,
"nigupta@...dia.com" <nigupta@...dia.com>,
"bhe@...hat.com" <bhe@...hat.com>,
"mateusznosek0@...il.com" <mateusznosek0@...il.com>,
"sh_def@....com" <sh_def@....com>,
"iamjoonsoo.kim@....com" <iamjoonsoo.kim@....com>,
"vinmenon@...eaurora.org" <vinmenon@...eaurora.org>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>
Subject: Re: 答复: [PATCH V2] mm: compaction: support triggering of proactive compaction by user
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
Powered by blists - more mailing lists