From: Dave Hansen <dave.hansen@intel.com>
To: David Rientjes <rientjes@google.com>
Cc: linux-kernel@vger.kernel.org,
Andrea Arcangeli <aarcange@redhat.com>,
Mel Gorman <mgorman@suse.de>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, Michal Hocko <mhocko@suse.cz>
Subject: Re: [RFC] mm: show message when updating min_free_kbytes in thp
Date: Thu, 02 Jan 2014 14:10:10 -0800 [thread overview]
Message-ID: <52C5E3C2.6020205@intel.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1401021357360.21537@chino.kir.corp.google.com>
On 01/02/2014 01:58 PM, David Rientjes wrote:
> On Thu, 2 Jan 2014, Dave Hansen wrote:
>
>>> min_free_kbytes may be updated during thp's initialization. Sometimes,
>>> this will change the value being set by user. Showing message will
>>> clarify this confusion.
>> ...
>>> - if (recommended_min > min_free_kbytes)
>>> + if (recommended_min > min_free_kbytes) {
>>> min_free_kbytes = recommended_min;
>>> + pr_info("min_free_kbytes is updated to %d by enabling transparent hugepage.\n",
>>> + min_free_kbytes);
>>> + }
>>
>> "updated" doesn't tell us much. It's also kinda nasty that if we enable
>> then disable THP, we end up with an elevated min_free_kbytes. Maybe we
>> should at least put something in that tells the user how to get back
>> where they were if they care:
>
> The default value of min_free_kbytes depends on the implementation of the
> VM regardless of any config options that you may have enabled. We don't
> specify what the non-thp default is in the kernel log, so why do we need
> to specify what the thp default is?
Let's say enabling THP made my system behave badly. How do I get it
back to the state before I enabled THP? The user has to have gone and
recorded what their min_free_kbytes was before turning THP on in order
to get it back to where it was. Folks also have to either plan in
advance (archiving *ALL* the sysctl settings), somehow *know* somehow
that THP can affect min_free_kbytes, or just plain be clairvoyant.
This seems like a pretty straightforward way to be transparent about
what the kernel mucked with, and exactly how it did it instead of
requiring clairvoyant sysadmins.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Dave Hansen <dave.hansen@intel.com>
To: David Rientjes <rientjes@google.com>
Cc: linux-kernel@vger.kernel.org,
Andrea Arcangeli <aarcange@redhat.com>,
Mel Gorman <mgorman@suse.de>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, Michal Hocko <mhocko@suse.cz>
Subject: Re: [RFC] mm: show message when updating min_free_kbytes in thp
Date: Thu, 02 Jan 2014 14:10:10 -0800 [thread overview]
Message-ID: <52C5E3C2.6020205@intel.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1401021357360.21537@chino.kir.corp.google.com>
On 01/02/2014 01:58 PM, David Rientjes wrote:
> On Thu, 2 Jan 2014, Dave Hansen wrote:
>
>>> min_free_kbytes may be updated during thp's initialization. Sometimes,
>>> this will change the value being set by user. Showing message will
>>> clarify this confusion.
>> ...
>>> - if (recommended_min > min_free_kbytes)
>>> + if (recommended_min > min_free_kbytes) {
>>> min_free_kbytes = recommended_min;
>>> + pr_info("min_free_kbytes is updated to %d by enabling transparent hugepage.\n",
>>> + min_free_kbytes);
>>> + }
>>
>> "updated" doesn't tell us much. It's also kinda nasty that if we enable
>> then disable THP, we end up with an elevated min_free_kbytes. Maybe we
>> should at least put something in that tells the user how to get back
>> where they were if they care:
>
> The default value of min_free_kbytes depends on the implementation of the
> VM regardless of any config options that you may have enabled. We don't
> specify what the non-thp default is in the kernel log, so why do we need
> to specify what the thp default is?
Let's say enabling THP made my system behave badly. How do I get it
back to the state before I enabled THP? The user has to have gone and
recorded what their min_free_kbytes was before turning THP on in order
to get it back to where it was. Folks also have to either plan in
advance (archiving *ALL* the sysctl settings), somehow *know* somehow
that THP can affect min_free_kbytes, or just plain be clairvoyant.
This seems like a pretty straightforward way to be transparent about
what the kernel mucked with, and exactly how it did it instead of
requiring clairvoyant sysadmins.
next prev parent reply other threads:[~2014-01-02 22:10 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-01 0:29 [RFC] mm: show message when updating min_free_kbytes in thp Han Pingtian
2014-01-01 0:29 ` Han Pingtian
2014-01-02 18:05 ` Dave Hansen
2014-01-02 18:05 ` Dave Hansen
2014-01-02 21:58 ` David Rientjes
2014-01-02 21:58 ` David Rientjes
2014-01-02 22:10 ` Dave Hansen [this message]
2014-01-02 22:10 ` Dave Hansen
2014-01-02 23:36 ` David Rientjes
2014-01-02 23:36 ` David Rientjes
2014-01-02 23:48 ` Dave Hansen
2014-01-02 23:48 ` Dave Hansen
2014-01-03 3:33 ` Han Pingtian
2014-01-03 3:33 ` Han Pingtian
2014-01-03 18:17 ` Dave Hansen
2014-01-03 18:17 ` Dave Hansen
2014-01-05 0:35 ` Han Pingtian
2014-01-05 0:35 ` Han Pingtian
2014-01-06 16:46 ` Michal Hocko
2014-01-06 16:46 ` Michal Hocko
2014-01-08 3:59 ` Han Pingtian
2014-01-08 3:59 ` Han Pingtian
2014-01-08 8:20 ` Han Pingtian
2014-01-08 8:20 ` Han Pingtian
2014-01-08 10:16 ` Michal Hocko
2014-01-08 10:16 ` Michal Hocko
2014-01-09 7:32 ` Han Pingtian
2014-01-09 7:32 ` Han Pingtian
2014-01-09 9:02 ` Michal Hocko
2014-01-09 9:02 ` Michal Hocko
2014-01-09 21:15 ` David Rientjes
2014-01-09 21:15 ` David Rientjes
2014-01-10 8:05 ` Michal Hocko
2014-01-10 8:05 ` Michal Hocko
2014-01-10 8:13 ` Andrew Morton
2014-01-10 8:13 ` Andrew Morton
2014-01-10 8:17 ` Michal Hocko
2014-01-10 8:17 ` Michal Hocko
2014-01-11 3:27 ` Han Pingtian
2014-01-11 3:27 ` Han Pingtian
2014-01-14 20:07 ` Han Pingtian
2014-01-14 20:07 ` Han Pingtian
2014-01-14 23:52 ` Andrew Morton
2014-01-14 23:52 ` Andrew Morton
2014-01-15 0:25 ` David Rientjes
2014-01-15 0:25 ` David Rientjes
2014-01-15 0:35 ` Andrew Morton
2014-01-15 0:35 ` Andrew Morton
2014-01-15 0:52 ` David Rientjes
2014-01-15 0:52 ` David Rientjes
2014-01-15 15:22 ` Mel Gorman
2014-01-15 15:22 ` Mel Gorman
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=52C5E3C2.6020205@intel.com \
--to=dave.hansen@intel.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@suse.cz \
--cc=rientjes@google.com \
/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.