linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mike Kravetz <mike.kravetz@oracle.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Song Liu <songliubraving@fb.com>,
	"Kirill A.Shutemov" <kirill.shutemov@linux.intel.com>,
	Mel Gorman <mgorman@techsingularity.net>,
	Vlastimil Babka <vbabka@suse.cz>,
	Khalid Aziz <khalid.aziz@oracle.com>,
	Matthew Wilcox <willy@infradead.org>,
	David Rientjes <rientjes@google.com>
Subject: Re: [PATCH v2] mm: Don't overwrite user min_free_kbytes, consider THP when adjusting
Date: Mon, 10 Feb 2020 16:02:22 -0800	[thread overview]
Message-ID: <834af4ca-5e3d-f034-fa48-f8672b75a9f2@oracle.com> (raw)
In-Reply-To: <20200210141903.413880202fa3e858e27272fd@linux-foundation.org>

On 2/10/20 2:19 PM, Andrew Morton wrote:
> On Mon, 10 Feb 2020 11:01:21 -0800 Mike Kravetz <mike.kravetz@oracle.com> 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.
> 
> Could we provide a detailed description of why this is considered to be
> a problem?  This is fairly easily guessable, but is there a real
> in-field bad user experience we can point at?

I do not have an example of a bad user experience.  This observation came
about when I was modifying min_free_kbytes while working on some other
issue.  To me, it seems like the current behavior is not what one would
expect.  Logging messages when we do not overwrite the user value and not
logging anything when we do seems a bit backward.

Changing this is not important to me.  It has been like this for quite some
time and I am not aware of any user complaints/issues.

>> Change code to never overwrite user defined value.  However, do log a
>> message (once per value) showing the value calculated in code.
>>
>> At system initialization time, both init_per_zone_wmark_min and
>> set_recommended_min_free_kbytes are called to set the initial value
>> for min_free_kbytes.  When memory is offlined or onlined, min_free_kbytes
>> is recalculated and adjusted based on the amount of memory.  However,
>> the adjustment for THP is not considered.  Here is an example from a 2
>> node system with 8GB of memory.
>>
>>  # cat /proc/sys/vm/min_free_kbytes
>>  90112
>>  # echo 0 > /sys/devices/system/node/node1/memory56/online
>>  # cat /proc/sys/vm/min_free_kbytes
>>  11243
>>  # echo 1 > /sys/devices/system/node/node1/memory56/online
>>  # cat /proc/sys/vm/min_free_kbytes
>>  11412
>>
>> One would expect that min_free_kbytes would return to it's original
>> value after the offline/online operations.
>>
>> Create a simple interface for THP/khugepaged based adjustment and
>> call this whenever min_free_kbytes is adjusted.
>>
>> ...
>>
>>  include/linux/khugepaged.h |  5 ++++
>>  mm/internal.h              |  2 ++
>>  mm/khugepaged.c            | 56 ++++++++++++++++++++++++++++++++------
>>  mm/page_alloc.c            | 35 ++++++++++++++++--------
> 
> min_free_kbytes gets a few mentions in Documentation/.  Should we make
> the appropriate updates there to bring this behavior to people's
> attention?

I'm happy to update the documentation to match current behavior.  Changing
the documentation may prompt people to ask if we should change the code. :)
-- 
Mike Kravetz


      reply	other threads:[~2020-02-11  0:04 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-10 19:01 [PATCH v2] mm: Don't overwrite user min_free_kbytes, consider THP when adjusting Mike Kravetz
2020-02-10 22:19 ` Andrew Morton
2020-02-11  0:02   ` Mike Kravetz [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=834af4ca-5e3d-f034-fa48-f8672b75a9f2@oracle.com \
    --to=mike.kravetz@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=khalid.aziz@oracle.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=rientjes@google.com \
    --cc=songliubraving@fb.com \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).