All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Mike Kravetz <mike.kravetz@oracle.com>
Cc: David Rientjes <rientjes@google.com>,
	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>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] mm: always consider THP when adjusting min_free_kbytes
Date: Thu, 6 Feb 2020 12:39:45 -0800	[thread overview]
Message-ID: <20200206203945.GZ8731@bombadil.infradead.org> (raw)
In-Reply-To: <2ba63021-d05c-a648-f280-6c751e01adf6@oracle.com>

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.


  parent reply	other threads:[~2020-02-06 20:39 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-04 19:41 [PATCH] mm: always consider THP when adjusting min_free_kbytes Mike Kravetz
2020-02-04 20:33 ` David Rientjes
2020-02-04 20:33   ` David Rientjes
2020-02-04 21:42   ` Mike Kravetz
2020-02-04 21:53     ` Matthew Wilcox
2020-02-05  0:33       ` Mike Kravetz
2020-02-06  1:36         ` Mike Kravetz
2020-02-06 20:09           ` Khalid Aziz
2020-02-06 20:39           ` Matthew Wilcox [this message]
2020-02-06 21:23             ` Mike Kravetz
2020-02-06 21:32               ` Matthew Wilcox
2020-02-10 18:58                 ` Mike Kravetz
2020-02-04 23:37     ` Khalid Aziz

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=20200206203945.GZ8731@bombadil.infradead.org \
    --to=willy@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mike.kravetz@oracle.com \
    --cc=rientjes@google.com \
    --cc=songliubraving@fb.com \
    --cc=vbabka@suse.cz \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.