set_recommended_min_free_kbytes need to honor min_free_kbytes set by the
user. Post start-of-day THP enable or memory hotplug operations can
lose user specified min_free_kbytes, in particular when it is higher than
calculated recommended value. Also modifying "recommended_min" variable
type to "int" from "unsigned long" to avoid undesired result noticed
during testing. It is due to comparing "unsigned long" with "int" type.
Signed-off-by: Vijay Balakrishna <[email protected]>
Cc: [email protected]
Reviewed-by: Pavel Tatashin <[email protected]>
---
mm/khugepaged.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index 4f7107476a6f..b4b753ba411a 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -2253,7 +2253,7 @@ static void set_recommended_min_free_kbytes(void)
{
struct zone *zone;
int nr_zones = 0;
- unsigned long recommended_min;
+ int recommended_min;
for_each_populated_zone(zone) {
/*
@@ -2280,12 +2280,12 @@ static void set_recommended_min_free_kbytes(void)
/* don't ever allow to reserve more than 5% of the lowmem */
recommended_min = min(recommended_min,
- (unsigned long) nr_free_buffer_pages() / 20);
+ (int) nr_free_buffer_pages() / 20);
recommended_min <<= (PAGE_SHIFT-10);
- if (recommended_min > min_free_kbytes) {
+ if (recommended_min > user_min_free_kbytes) {
if (user_min_free_kbytes >= 0)
- pr_info("raising min_free_kbytes from %d to %lu to help transparent hugepage allocations\n",
+ pr_info("raising min_free_kbytes from %d to %d to help transparent hugepage allocations\n",
min_free_kbytes, recommended_min);
min_free_kbytes = recommended_min;
--
2.28.0
On Tue 15-09-20 14:10:58, Vijay Balakrishna wrote:
> set_recommended_min_free_kbytes need to honor min_free_kbytes set by the
> user. Post start-of-day THP enable or memory hotplug operations can
> lose user specified min_free_kbytes, in particular when it is higher than
> calculated recommended value. Also modifying "recommended_min" variable
> type to "int" from "unsigned long" to avoid undesired result noticed
> during testing. It is due to comparing "unsigned long" with "int" type.
>
> Signed-off-by: Vijay Balakrishna <[email protected]>
> Cc: [email protected]
> Reviewed-by: Pavel Tatashin <[email protected]>
> ---
> mm/khugepaged.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> index 4f7107476a6f..b4b753ba411a 100644
> --- a/mm/khugepaged.c
> +++ b/mm/khugepaged.c
> @@ -2253,7 +2253,7 @@ static void set_recommended_min_free_kbytes(void)
> {
> struct zone *zone;
> int nr_zones = 0;
> - unsigned long recommended_min;
> + int recommended_min;
>
> for_each_populated_zone(zone) {
> /*
> @@ -2280,12 +2280,12 @@ static void set_recommended_min_free_kbytes(void)
>
> /* don't ever allow to reserve more than 5% of the lowmem */
> recommended_min = min(recommended_min,
> - (unsigned long) nr_free_buffer_pages() / 20);
> + (int) nr_free_buffer_pages() / 20);
nr_free_buffer_pages can oveflow in int on very large machines.
> recommended_min <<= (PAGE_SHIFT-10);
>
> - if (recommended_min > min_free_kbytes) {
> + if (recommended_min > user_min_free_kbytes) {
This can decrease the size theoretically. Because user_min_free_kbytes
is -1 by default and recommended_min might be <= min_free_kbytes.
You need to check both. Also can we make user_min_free_kbytes 0 by
default? From a quick look, nobody should really care.
> if (user_min_free_kbytes >= 0)
> - pr_info("raising min_free_kbytes from %d to %lu to help transparent hugepage allocations\n",
> + pr_info("raising min_free_kbytes from %d to %d to help transparent hugepage allocations\n",
> min_free_kbytes, recommended_min);
>
> min_free_kbytes = recommended_min;
> --
> 2.28.0
>
--
Michal Hocko
SUSE Labs
On 9/16/2020 12:59 AM, Michal Hocko wrote:
> On Tue 15-09-20 14:10:58, Vijay Balakrishna wrote:
>> set_recommended_min_free_kbytes need to honor min_free_kbytes set by the
>> user. Post start-of-day THP enable or memory hotplug operations can
>> lose user specified min_free_kbytes, in particular when it is higher than
>> calculated recommended value. Also modifying "recommended_min" variable
>> type to "int" from "unsigned long" to avoid undesired result noticed
>> during testing. It is due to comparing "unsigned long" with "int" type.
>>
>> Signed-off-by: Vijay Balakrishna <[email protected]>
>> Cc: [email protected]
>> Reviewed-by: Pavel Tatashin <[email protected]>
>> ---
>> mm/khugepaged.c | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
>> index 4f7107476a6f..b4b753ba411a 100644
>> --- a/mm/khugepaged.c
>> +++ b/mm/khugepaged.c
>> @@ -2253,7 +2253,7 @@ static void set_recommended_min_free_kbytes(void)
>> {
>> struct zone *zone;
>> int nr_zones = 0;
>> - unsigned long recommended_min;
>> + int recommended_min;
>>
>> for_each_populated_zone(zone) {
>> /*
>> @@ -2280,12 +2280,12 @@ static void set_recommended_min_free_kbytes(void)
>>
>> /* don't ever allow to reserve more than 5% of the lowmem */
>> recommended_min = min(recommended_min,
>> - (unsigned long) nr_free_buffer_pages() / 20);
>> + (int) nr_free_buffer_pages() / 20);
>
> nr_free_buffer_pages can oveflow in int on very large machines.
Good point. I will address it.
>
>> recommended_min <<= (PAGE_SHIFT-10);
>>
>> - if (recommended_min > min_free_kbytes) {
>> + if (recommended_min > user_min_free_kbytes) {
>
> This can decrease the size theoretically. Because user_min_free_kbytes
> is -1 by default and recommended_min might be <= min_free_kbytes.
>
> You need to check both. Also can we make user_min_free_kbytes 0 by
> default? From a quick look, nobody should really care.
Let me rework.
Thanks,
Vijay
>
>> if (user_min_free_kbytes >= 0)
>> - pr_info("raising min_free_kbytes from %d to %lu to help transparent hugepage allocations\n",
>> + pr_info("raising min_free_kbytes from %d to %d to help transparent hugepage allocations\n",
>> min_free_kbytes, recommended_min);
>>
>> min_free_kbytes = recommended_min;
>> --
>> 2.28.0
>>
>
Hi
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.8.10, v5.4.66, v4.19.146, v4.14.198, v4.9.236, v4.4.236.
v5.8.10: Build OK!
v5.4.66: Build OK!
v4.19.146: Build OK!
v4.14.198: Build OK!
v4.9.236: Build OK!
v4.4.236: Failed to apply! Possible dependencies:
0b57d6ba0bd1 ("mm/mmap.c: remove redundant local variables for may_expand_vm()")
1170532bb49f ("mm: convert printk(KERN_<LEVEL> to pr_<level>")
5a6e75f8110c ("shmem: prepare huge= mount option and sysfs knob")
756a025f0009 ("mm: coalesce split strings")
84638335900f ("mm: rework virtual memory accounting")
8cee852ec53f ("mm, procfs: breakdown RSS for anon, shmem and file in /proc/pid/status")
b46e756f5e47 ("thp: extract khugepaged from mm/huge_memory.c")
d07e22597d1d ("mm: mmap: add new /proc tunable for mmap_base ASLR")
d977d56ce5b3 ("mm: warn about VmData over RLIMIT_DATA")
d9fe4fab1197 ("x86/mm/pat: Add untrack_pfn_moved for mremap")
eca56ff906bd ("mm, shmem: add internal shmem resident memory accounting")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks
Sasha