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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 28 May 2021 22:32:12 +0530
From:   Charan Teja Kalla <charante@...eaurora.org>
To:     Vlastimil Babka <vbabka@...e.cz>, akpm@...ux-foundation.org,
        mcgrof@...nel.org, keescook@...omium.org, yzaikin@...gle.com,
        nigupta@...dia.com, bhe@...hat.com, mateusznosek0@...il.com,
        sh_def@....com, iamjoonsoo.kim@....com, vinmenon@...eaurora.org
Cc:     linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        linux-fsdevel@...r.kernel.org,
        Linux API <linux-api@...r.kernel.org>
Subject: Re: [PATCH V2] mm: compaction: support triggering of proactive
 compaction by user

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@...eaurora.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