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] [day] [month] [year] [list]

Message-ID: <c8e7f2dd-c6ca-6b1d-0a92-52a24771a15f@codeaurora.org>
Date:   Sat, 29 May 2021 08:27:41 +0530
From:   Charan Teja Kalla <charante@...eaurora.org>
To:     Nitin Gupta <nigupta@...dia.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>,
        "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 Nitin for your inputs.

On 5/28/2021 5:22 AM, Nitin Gupta wrote:
>> First, Does the user doing the above steps are valid?
>> If yes, then we should guarantee to the user that proactive compaction
>> atleast tried to run when the user changed the proactiveness.
>> If not, I feel, we should document that 'once user changed the
>> compaction_proactiveness, he need to wait atleast
>> HPAGE_FRAG_CHECK_INTERVAL_MSEC before considering that the value he
>> tried to set is effective and proactive compaction tried to run on that'.
>> Doesn't this seem okay?
> Proactive compaction does not guarantee if the kernel will be able to achieve
> fragmentation targets implied from the compaction_proactiveness sysctl. It also
> does not guarantee how much time it will take to reach desired fragmentation
> levels (if at all possible). 

Shouldn't we add these lines in the Documentation. Will raise a patch If
it is fine.


> Maybe add a Kconfig parameter for setting
> HPAGE_FRAG_CHECK_INTERVAL_MSEC to say 1msec?

I really don't have an use case to make the
HPAGE_FRAG_CHECK_INTERVAL_MSEC as config option. But should we make it
as Kconfig option and let the user decide how aggressively proactive
compaction should do the job of system defragmentation in his system?
Selection will be limited in the range of 10msec to 500msec, defaults to
500msec.

--Thanks

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