linux-kernel - Re: [PATCH] mm: always consider THP when adjusting min_free

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]

Date:   Mon, 10 Feb 2020 10:58:01 -0800
From:   Mike Kravetz <mike.kravetz@...cle.com>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     David Rientjes <rientjes@...gle.com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, Song Liu <songliubraving@...com>,
        "Kirill A.Shutemov" <kirill.shutemov@...ux.intel.com>,
        Mel Gorman <mgorman@...hsingularity.net>,
        Vlastimil Babka <vbabka@...e.cz>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] mm: always consider THP when adjusting min_free_kbytes

On 2/6/20 1:32 PM, Matthew Wilcox wrote:
> On Thu, Feb 06, 2020 at 01:23:21PM -0800, Mike Kravetz wrote:
>> On 2/6/20 12:39 PM, Matthew Wilcox wrote:
>>> On Wed, Feb 05, 2020 at 05:36:44PM -0800, Mike Kravetz wrote:
>>>> The value of min_free_kbytes is calculated in two routines:
>>>> 1) init_per_zone_wmark_min based on available memory
>>>> 2) set_recommended_min_free_kbytes may reserve extra space for
>>>>    THP allocations
>>>>
>>>> In both of these routines, a user defined min_free_kbytes value will
>>>> be overwritten if the value calculated in the code is larger. No message
>>>> is logged if the user value is overwritten.
>>>>
>>>> Change code to never overwrite user defined value.  However, do log a
>>>> message (once per value) showing the value calculated in code.
>>>
>>> But what if the user set min_free_kbytes to, say, half of system memory,
>>> and then hot-unplugs three quarters of their memory?  I think the kernel
>>> should protect itself against such foolishness.
>>
>> I'm not sure what we should set it to in this case.  Previously you said,
>>
>>>> I'm reluctant to suggest we do a more complex adjustment of the value
>>>> (eg figure out what the adjustment would have been, then apply some
>>>> fraction of that adjustment to keep the ratios in proportion) because
>>>> we don't really know why they adjusted it.
>>
>> So, I suspect you would suggest setting it to the default computed value?
>> But then, when do we start adjusting?  What if they only remove a small
>> amount of memory?  And, then add the same amount back in?
> 
> I don't know about the default computed value ... we don't seem to have
> any protection against the user setting min_free_kbytes to double the
> amount of memory in the machine today.  Which would presumably cause
> problems if I asked to maintain 32GB free at all times on my 16GB laptop?
> 
> Maybe we should have such protection?

I am not going to attempt to define parameters for user defined values
of min_free_kbytes.  Someone smarter than me can take that on.  Documentation
is pretty clear that user is allowed to do bad things which will immediately
cause them problems.

I'm going to explicitly send out the v2 version of patch.  It is not something
I feel strongly about.  Just an attempt to clean up some inconsistencies
observed while looking at something else.
-- 
Mike Kravetz