Re: [PATCH V2] mm: compaction: support triggering of proactive compaction by user

[Charan Teja Kalla <charante@codeaurora.org>]

Thanks Vlastimil for your inputs!!

On 5/28/2021 8:49 PM, Vlastimil Babka wrote:
> On 5/18/21 3:37 PM, Charan Teja Reddy wrote:
>> The proactive compaction[1] gets triggered for every 500msec and run
>> compaction on the node for COMPACTION_HPAGE_ORDER (usually order-9)
>> pages based on the value set to sysctl.compaction_proactiveness.
>> Triggering the compaction for every 500msec in search of
>> COMPACTION_HPAGE_ORDER pages is not needed for all applications,
>> especially on the embedded system usecases which may have few MB's of
>> RAM. Enabling the proactive compaction in its state will endup in
>> running almost always on such systems.
>> This triggering of proactive compaction is done on a write to
>> sysctl.compaction_proactiveness by user.
>>
>> [1]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=facdaa917c4d5a376d09d25865f5a863f906234a
>>
>> Signed-off-by: Charan Teja Reddy <charante@codeaurora.org>
> Cancelling all current sleeps immediately when the controlling variable changes
> doesn't sound wrong to me.

Agree that cancelling sleeps is not wrong here.

> A question below:
> 
>> ---
>> changes in V2: 
>>     - remove /proc interface trigger for proactive compaction
>>     - Intention is same that add a way to trigger proactive compaction by user.
>>  			if (proactive_defer) {
>>  				proactive_defer--;
>> -				continue;
>> +				goto loop;
> I don't understand this part. If we kick kcompactd from the sysctl handler
> because we are changing proactiveness, shouldn't we also discard any accumulated
> defer score?

Yes, we should be discarding the accumulated defer score when user
changing the proactiveness, even when writing higher proactiveness value
than for which it was deferred. Will raise V3 for this.

> 

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