Re: [PATCH v2] mm: avoid inconsistent "boosts" when updating the high and low watermarks

[David Rientjes <rientjes@google.com>]

On Fri, 21 Jun 2019, Alan Jenkins wrote:

> When setting the low and high watermarks we use min_wmark_pages(zone).
> I guess this was to reduce the line length.  Then this macro was modified
> to include zone->watermark_boost.  So we needed to set watermark_boost
> before we set the high and low watermarks... but we did not.
> 
> It seems mostly harmless.  It might set the watermarks a bit higher than
> needed: when 1) the watermarks have been "boosted" and 2) you then
> triggered __setup_per_zone_wmarks() (by setting one of the sysctls, or
> hotplugging memory...).
> 
> I noticed it because it also breaks the documented equality
> (high - low == low - min).  Below is an example of reproducing the bug.
> 
> First sample.  Equality is met (high - low == low - min):
> 
> Node 0, zone   Normal
>   pages free     11962
>         min      9531
>         low      11913
>         high     14295
>         spanned  1173504
>         present  1173504
>         managed  1134235
> 
> A later sample.  Something has caused us to boost the watermarks:
> 
> Node 0, zone   Normal
>   pages free     12614
>         min      10043
>         low      12425
>         high     14807
> 
> Now trigger the watermarks to be recalculated.  "cd /proc/sys/vm" and
> "cat watermark_scale_factor > watermark_scale_factor".  Then the watermarks
> are boosted inconsistently.  The equality is broken:
> 
> Node 0, zone   Normal
>   pages free     12412
>         min      9531
>         low      12425
>         high     14807
> 
> 14807 - 12425 = 2382
> 12425 -  9531 = 2894
> 
> Co-developed-by: Vlastimil Babka <vbabka@suse.cz>
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> Signed-off-by: Alan Jenkins <alan.christopher.jenkins@gmail.com>
> Fixes: 1c30844d2dfe ("mm: reclaim small amounts of memory when an external
>                       fragmentation event occurs")
> Acked-by: Mel Gorman <mgorman@techsingularity.net>

Acked-by: David Rientjes <rientjes@google.com>