[RFC] kswapd aggressiveness with watermark_scale_factor

[RFC] kswapd aggressiveness with watermark_scale_factor

[Vinayak Menon]

Hi,

It is observed that watermark_scale_factor when used to reduce thundering herds
in direct reclaim, reduces the direct reclaims, but results in unnecessary reclaim
due to kswapd running for long after being woken up. The tests are done with 4 GB
of RAM and the tests done are multibuild and another which opens a set of apps
sequentially on Android and repeating the sequence N times. The tests are done on
4.9 kernel.

The issue seems to be because of watermark_scale_factor creating larger gap between
low and high watermarks. The following results are with watermark_scale_factor of 120
and the other with watermark_scale_factor 120 with a reduced gap between low and
high watermarks. The patch used to reduce the gap is given below. The min-low gap is
untouched. It can be seen that with the reduced low-high gap, the direct reclaims are
almost same as base, but with 45% less pgpgin. Reduced low-high gap improves the
latency by around 11% in the sequential app test due to lesser IO and kswapd activity.

A A A A A A A A A A A A A A A A A A A A A A  wsf-120-defaultA A A A A  wsf-120-reduced-low-high-gap
workingset_activateA A A  15120206A A A A A A A A A A A A  8319182
pgpginA A A A A A A A A A A A A A A A  269795482A A A A A A A A A A A  147928581
allocstallA A A A A A A A A A A A  1406A A A A A A A A A A A A A A A A  1498
pgsteal_kswapdA A A A A A A A  68676960A A A A A A A A A A A A  38105142
slabs_scannedA A A A A A A A A  94181738A A A A A A A A A A A A  49085755

This is the diff of wsf-120-reduced-low-high-gap for comments. The patch considers
low-high gap as a fraction of min-low gap, and the fraction a function of managed pages,
increasing non-linearly. The multiplier 4 is was chosen as a reasonable value which does
not alter the low-high gap much from the base for large machines.

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 3a11a50..749d1eb 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6898,7 +6898,11 @@ static void __setup_per_zone_wmarks(void)
A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A  watermark_scale_factor, 10000));

A A A A A A A A A A A A A A A  zone->watermark[WMARK_LOW]A  = min_wmark_pages(zone) + tmp;
-A A A A A A A A A A A A A A  zone->watermark[WMARK_HIGH] = min_wmark_pages(zone) + tmp * 2;
+
+A A A A A A A A A A A A A A  tmp = clamp_t(u64, mult_frac(tmp, int_sqrt(4 * zone->managed_pages),
+A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A  10000), min_wmark_pages(zone) >> 2 , tmp);
+
+A A A A A A A A A A A A A A  zone->watermark[WMARK_HIGH] = low_wmark_pages(zone) + tmp;

A A A A A A A A A A A A A A A  spin_unlock_irqrestore(&zone->lock, flags);
A A A A A A A  }

With the patch,
With watermark_scale_factor as default 10, the low-high gap:
unchanged for 140G at 143M,
for 65G, reduces from 65M to 53M
for 4GB, reduces from 4M to 1M

With watermark_scale_factor 120, the low-high gap:
unchanged for 140G
for 65G, reduces from 786M to 644M
for 4GB, reduces from 49M to 10M

Thanks,
Vinayak

--
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>

Re: [RFC] kswapd aggressiveness with watermark_scale_factor

[Vinayak Menon]

On 1/24/2018 9:25 PM, Vinayak Menon wrote:
> Hi,
>
> It is observed that watermark_scale_factor when used to reduce thundering herds
> in direct reclaim, reduces the direct reclaims, but results in unnecessary reclaim
> due to kswapd running for long after being woken up. The tests are done with 4 GB
> of RAM and the tests done are multibuild and another which opens a set of apps
> sequentially on Android and repeating the sequence N times. The tests are done on
> 4.9 kernel.
>
> The issue seems to be because of watermark_scale_factor creating larger gap between
> low and high watermarks. The following results are with watermark_scale_factor of 120
> and the other with watermark_scale_factor 120 with a reduced gap between low and
> high watermarks. The patch used to reduce the gap is given below. The min-low gap is
> untouched. It can be seen that with the reduced low-high gap, the direct reclaims are
> almost same as base, but with 45% less pgpgin. Reduced low-high gap improves the
> latency by around 11% in the sequential app test due to lesser IO and kswapd activity.
>
> A A A A A A A A A A A A A A A A A A A A A A  wsf-120-defaultA A A A A  wsf-120-reduced-low-high-gap
> workingset_activateA A A  15120206A A A A A A A A A A A A  8319182
> pgpginA A A A A A A A A A A A A A A A  269795482A A A A A A A A A A A  147928581
> allocstallA A A A A A A A A A A A  1406A A A A A A A A A A A A A A A A  1498
> pgsteal_kswapdA A A A A A A A  68676960A A A A A A A A A A A A  38105142
> slabs_scannedA A A A A A A A A  94181738A A A A A A A A A A A A  49085755
>
> This is the diff of wsf-120-reduced-low-high-gap for comments. The patch considers
> low-high gap as a fraction of min-low gap, and the fraction a function of managed pages,
> increasing non-linearly. The multiplier 4 is was chosen as a reasonable value which does
> not alter the low-high gap much from the base for large machines.
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 3a11a50..749d1eb 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -6898,7 +6898,11 @@ static void __setup_per_zone_wmarks(void)
> A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A  watermark_scale_factor, 10000));
>
> A A A A A A A A A A A A A A A  zone->watermark[WMARK_LOW]A  = min_wmark_pages(zone) + tmp;
> -A A A A A A A A A A A A A A  zone->watermark[WMARK_HIGH] = min_wmark_pages(zone) + tmp * 2;
> +
> +A A A A A A A A A A A A A A  tmp = clamp_t(u64, mult_frac(tmp, int_sqrt(4 * zone->managed_pages),
> +A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A  10000), min_wmark_pages(zone) >> 2 , tmp);
> +
> +A A A A A A A A A A A A A A  zone->watermark[WMARK_HIGH] = low_wmark_pages(zone) + tmp;
>
> A A A A A A A A A A A A A A A  spin_unlock_irqrestore(&zone->lock, flags);
> A A A A A A A  }
>
> With the patch,
> With watermark_scale_factor as default 10, the low-high gap:
> unchanged for 140G at 143M,
> for 65G, reduces from 65M to 53M
> for 4GB, reduces from 4M to 1M
>
> With watermark_scale_factor 120, the low-high gap:
> unchanged for 140G
> for 65G, reduces from 786M to 644M
> for 4GB, reduces from 49M to 10M
>
> Thanks,
> Vinayak

Ping for comments, thanks.

--
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>

Re: [RFC] kswapd aggressiveness with watermark_scale_factor

[Mel Gorman]

On Wed, Jan 24, 2018 at 09:25:37PM +0530, Vinayak Menon wrote:
> Hi,
> 
> It is observed that watermark_scale_factor when used to reduce thundering herds
> in direct reclaim, reduces the direct reclaims, but results in unnecessary reclaim
> due to kswapd running for long after being woken up. The tests are done with 4 GB
> of RAM and the tests done are multibuild and another which opens a set of apps
> sequentially on Android and repeating the sequence N times. The tests are done on
> 4.9 kernel.
> 
> The issue seems to be because of watermark_scale_factor creating larger gap between
> low and high watermarks. The following results are with watermark_scale_factor of 120
> and the other with watermark_scale_factor 120 with a reduced gap between low and
> high watermarks. The patch used to reduce the gap is given below. The min-low gap is
> untouched. It can be seen that with the reduced low-high gap, the direct reclaims are
> almost same as base, but with 45% less pgpgin. Reduced low-high gap improves the
> latency by around 11% in the sequential app test due to lesser IO and kswapd activity.
> 
>                        wsf-120-default      wsf-120-reduced-low-high-gap
> workingset_activate    15120206             8319182
> pgpgin                 269795482            147928581
> allocstall             1406                 1498
> pgsteal_kswapd         68676960             38105142
> slabs_scanned          94181738             49085755
> 
> This is the diff of wsf-120-reduced-low-high-gap for comments. The patch considers
> low-high gap as a fraction of min-low gap, and the fraction a function of managed pages,
> increasing non-linearly. The multiplier 4 is was chosen as a reasonable value which does
> not alter the low-high gap much from the base for large machines.
> 

This needs a proper changelog, signed-offs and a comment on the reasoning
behind the new min value for the gap between low and high and how it
was derived.  It appears the equation was designed such at the gap, as
a percentage of the zone size, would shrink according as the zone size
increases but I'm not 100% certain that was the intent. That should be
explained and why not just using "tmp >> 2" would have problems.

It would also need review/testing by Johannes to ensure that there is no
reintroduction of the problems that watermark_scale_factor was designed
to solve.

> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 3a11a50..749d1eb 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -6898,7 +6898,11 @@ static void __setup_per_zone_wmarks(void)
>                                       watermark_scale_factor, 10000));
> 
>                 zone->watermark[WMARK_LOW]  = min_wmark_pages(zone) + tmp;
> -               zone->watermark[WMARK_HIGH] = min_wmark_pages(zone) + tmp * 2;
> +
> +               tmp = clamp_t(u64, mult_frac(tmp, int_sqrt(4 * zone->managed_pages),
> +                               10000), min_wmark_pages(zone) >> 2 , tmp);
> +
> +               zone->watermark[WMARK_HIGH] = low_wmark_pages(zone) + tmp;
> 
>                 spin_unlock_irqrestore(&zone->lock, flags);
>         }
> 
> With the patch,
> With watermark_scale_factor as default 10, the low-high gap:
> unchanged for 140G at 143M,
> for 65G, reduces from 65M to 53M
> for 4GB, reduces from 4M to 1M
> 
> With watermark_scale_factor 120, the low-high gap:
> unchanged for 140G
> for 65G, reduces from 786M to 644M
> for 4GB, reduces from 49M to 10M
> 

This information should also be in the changelog.

-- 
Mel Gorman
SUSE Labs

--
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>

Re: [RFC] kswapd aggressiveness with watermark_scale_factor

[Vinayak Menon]

On 2/15/2018 6:10 PM, Mel Gorman wrote:
> On Wed, Jan 24, 2018 at 09:25:37PM +0530, Vinayak Menon wrote:
>> Hi,
>>
>> It is observed that watermark_scale_factor when used to reduce thundering herds
>> in direct reclaim, reduces the direct reclaims, but results in unnecessary reclaim
>> due to kswapd running for long after being woken up. The tests are done with 4 GB
>> of RAM and the tests done are multibuild and another which opens a set of apps
>> sequentially on Android and repeating the sequence N times. The tests are done on
>> 4.9 kernel.
>>
>> The issue seems to be because of watermark_scale_factor creating larger gap between
>> low and high watermarks. The following results are with watermark_scale_factor of 120
>> and the other with watermark_scale_factor 120 with a reduced gap between low and
>> high watermarks. The patch used to reduce the gap is given below. The min-low gap is
>> untouched. It can be seen that with the reduced low-high gap, the direct reclaims are
>> almost same as base, but with 45% less pgpgin. Reduced low-high gap improves the
>> latency by around 11% in the sequential app test due to lesser IO and kswapd activity.
>>
>>                        wsf-120-default      wsf-120-reduced-low-high-gap
>> workingset_activate    15120206             8319182
>> pgpgin                 269795482            147928581
>> allocstall             1406                 1498
>> pgsteal_kswapd         68676960             38105142
>> slabs_scanned          94181738             49085755
>>
>> This is the diff of wsf-120-reduced-low-high-gap for comments. The patch considers
>> low-high gap as a fraction of min-low gap, and the fraction a function of managed pages,
>> increasing non-linearly. The multiplier 4 is was chosen as a reasonable value which does
>> not alter the low-high gap much from the base for large machines.
>>
> This needs a proper changelog, signed-offs and a comment on the reasoning
> behind the new min value for the gap between low and high and how it
> was derived.  It appears the equation was designed such at the gap, as
> a percentage of the zone size, would shrink according as the zone size
> increases but I'm not 100% certain that was the intent. That should be
> explained and why not just using "tmp >> 2" would have problems.
>
> It would also need review/testing by Johannes to ensure that there is no
> reintroduction of the problems that watermark_scale_factor was designed
> to solve.

Sorry for the delayed response. I will send a patch with the details. The equation was designed so that the
low-high gap is small for smaller RAM sizes and tends towards min-low gap as the RAM size increases. This
was done considering that it should not have a bad effect on for 140G configuration which Johannes had taken
taken as example when watermark_scale_factor was introduced, also assuming that the thrashing seen due to
low-high gap would be visible only on low RAM devices.

>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index 3a11a50..749d1eb 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -6898,7 +6898,11 @@ static void __setup_per_zone_wmarks(void)
>>                                       watermark_scale_factor, 10000));
>>
>>                 zone->watermark[WMARK_LOW]  = min_wmark_pages(zone) + tmp;
>> -               zone->watermark[WMARK_HIGH] = min_wmark_pages(zone) + tmp * 2;
>> +
>> +               tmp = clamp_t(u64, mult_frac(tmp, int_sqrt(4 * zone->managed_pages),
>> +                               10000), min_wmark_pages(zone) >> 2 , tmp);
>> +
>> +               zone->watermark[WMARK_HIGH] = low_wmark_pages(zone) + tmp;
>>
>>                 spin_unlock_irqrestore(&zone->lock, flags);
>>         }
>>
>> With the patch,
>> With watermark_scale_factor as default 10, the low-high gap:
>> unchanged for 140G at 143M,
>> for 65G, reduces from 65M to 53M
>> for 4GB, reduces from 4M to 1M
>>
>> With watermark_scale_factor 120, the low-high gap:
>> unchanged for 140G
>> for 65G, reduces from 786M to 644M
>> for 4GB, reduces from 49M to 10M
>>
> This information should also be in the changelog.

Sure.

Thanks,
Vinayak

--
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>

Re: [RFC] kswapd aggressiveness with watermark_scale_factor

[Mel Gorman]

On Wed, Mar 07, 2018 at 02:47:09PM +0530, Vinayak Menon wrote:
> > This needs a proper changelog, signed-offs and a comment on the reasoning
> > behind the new min value for the gap between low and high and how it
> > was derived.  It appears the equation was designed such at the gap, as
> > a percentage of the zone size, would shrink according as the zone size
> > increases but I'm not 100% certain that was the intent. That should be
> > explained and why not just using "tmp >> 2" would have problems.
> >
> > It would also need review/testing by Johannes to ensure that there is no
> > reintroduction of the problems that watermark_scale_factor was designed
> > to solve.
> 
> Sorry for the delayed response. I will send a patch with the details. The equation was designed so that the
> low-high gap is small for smaller RAM sizes and tends towards min-low gap as the RAM size increases. This
> was done considering that it should not have a bad effect on for 140G configuration which Johannes had taken
> taken as example when watermark_scale_factor was introduced, also assuming that the thrashing seen due to
> low-high gap would be visible only on low RAM devices.
> 

If you do spin a new version with corrections made, be very careful to
note that the figures you supply are based on a kernel without THP because
that's where it makes a real difference. The differences with THP enabled
are very different as that alters min_free_kbytes and by extention, it
changes the point where your patch has an effect on the distance between
watermarks. It does mean that a test you say definitely works will not
necessary be visible to someone who tests the same patch on x86-64. Maybe
no one will notice or care but if you get a report about the results being
unreproducible then I suggest you check first if THP was enabled.

-- 
Mel Gorman
SUSE Labs

--
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>

Re: [RFC] kswapd aggressiveness with watermark_scale_factor

[Vinayak Menon]

On 3/7/2018 3:48 PM, Mel Gorman wrote:
> On Wed, Mar 07, 2018 at 02:47:09PM +0530, Vinayak Menon wrote:
>>> This needs a proper changelog, signed-offs and a comment on the reasoning
>>> behind the new min value for the gap between low and high and how it
>>> was derived.  It appears the equation was designed such at the gap, as
>>> a percentage of the zone size, would shrink according as the zone size
>>> increases but I'm not 100% certain that was the intent. That should be
>>> explained and why not just using "tmp >> 2" would have problems.
>>>
>>> It would also need review/testing by Johannes to ensure that there is no
>>> reintroduction of the problems that watermark_scale_factor was designed
>>> to solve.
>> Sorry for the delayed response. I will send a patch with the details. The equation was designed so that the
>> low-high gap is small for smaller RAM sizes and tends towards min-low gap as the RAM size increases. This
>> was done considering that it should not have a bad effect on for 140G configuration which Johannes had taken
>> taken as example when watermark_scale_factor was introduced, also assuming that the thrashing seen due to
>> low-high gap would be visible only on low RAM devices.
>>
> If you do spin a new version with corrections made, be very careful to
> note that the figures you supply are based on a kernel without THP because
> that's where it makes a real difference. The differences with THP enabled
> are very different as that alters min_free_kbytes and by extention, it
> changes the point where your patch has an effect on the distance between
> watermarks. It does mean that a test you say definitely works will not
> necessary be visible to someone who tests the same patch on x86-64. Maybe
> no one will notice or care but if you get a report about the results being
> unreproducible then I suggest you check first if THP was enabled.

Sure. The results provided earlier were without THP.

--
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>