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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
