Re: [RFC] mm: show message when updating min_free_kbytes in thp

[Dave Hansen]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/