lkml.org 
[lkml]   [2020]   [Jun]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [PATCH] mm, page_alloc: skip ->waternark_boost for atomic order-0 allocations
On Tue, 19 May 2020 15:28:04 +0530 Charan Teja Reddy <charante@codeaurora.org> wrote:

> When boosting is enabled, it is observed that rate of atomic order-0
> allocation failures are high due to the fact that free levels in the
> system are checked with ->watermark_boost offset. This is not a problem
> for sleepable allocations but for atomic allocations which looks like
> regression.
>
> This problem is seen frequently on system setup of Android kernel
> running on Snapdragon hardware with 4GB RAM size. When no extfrag event
> occurred in the system, ->watermark_boost factor is zero, thus the
> watermark configurations in the system are:
> _watermark = (
> [WMARK_MIN] = 1272, --> ~5MB
> [WMARK_LOW] = 9067, --> ~36MB
> [WMARK_HIGH] = 9385), --> ~38MB
> watermark_boost = 0
>
> After launching some memory hungry applications in Android which can
> cause extfrag events in the system to an extent that ->watermark_boost
> can be set to max i.e. default boost factor makes it to 150% of high
> watermark.
> _watermark = (
> [WMARK_MIN] = 1272, --> ~5MB
> [WMARK_LOW] = 9067, --> ~36MB
> [WMARK_HIGH] = 9385), --> ~38MB
> watermark_boost = 14077, -->~57MB
>
> With default system configuration, for an atomic order-0 allocation to
> succeed, having free memory of ~2MB will suffice. But boosting makes
> the min_wmark to ~61MB thus for an atomic order-0 allocation to be
> successful system should have minimum of ~23MB of free memory(from
> calculations of zone_watermark_ok(), min = 3/4(min/2)). But failures are
> observed despite system is having ~20MB of free memory. In the testing,
> this is reproducible as early as first 300secs since boot and with
> furtherlowram configurations(<2GB) it is observed as early as first
> 150secs since boot.
>
> These failures can be avoided by excluding the ->watermark_boost in
> watermark caluculations for atomic order-0 allocations.

Do we have any additional reviewer input on this one?

> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3709,6 +3709,18 @@ static bool zone_allows_reclaim(struct zone *local_zone, struct zone *zone)
> }
>
> mark = wmark_pages(zone, alloc_flags & ALLOC_WMARK_MASK);
> + /*
> + * Allow GFP_ATOMIC order-0 allocations to exclude the
> + * zone->watermark_boost in its watermark calculations.
> + * We rely on the ALLOC_ flags set for GFP_ATOMIC
> + * requests in gfp_to_alloc_flags() for this. Reason not to
> + * use the GFP_ATOMIC directly is that we want to fall back
> + * to slow path thus wake up kswapd.
> + */
> + if (unlikely(!order && !(alloc_flags & ALLOC_WMARK_MASK) &&
> + (alloc_flags & (ALLOC_HARDER | ALLOC_HIGH)))) {
> + mark = zone->_watermark[WMARK_MIN];
> + }
> if (!zone_watermark_fast(zone, order, mark,
> ac->highest_zoneidx, alloc_flags)) {
> int ret;

It would seem smart to do

--- a/mm/page_alloc.c~mm-page_alloc-skip-waternark_boost-for-atomic-order-0-allocations-fix
+++ a/mm/page_alloc.c
@@ -3745,7 +3745,6 @@ retry:
}
}

- mark = wmark_pages(zone, alloc_flags & ALLOC_WMARK_MASK);
/*
* Allow GFP_ATOMIC order-0 allocations to exclude the
* zone->watermark_boost in their watermark calculations.
@@ -3757,6 +3756,8 @@ retry:
if (unlikely(!order && !(alloc_flags & ALLOC_WMARK_MASK) &&
(alloc_flags & (ALLOC_HARDER | ALLOC_HIGH)))) {
mark = zone->_watermark[WMARK_MIN];
+ } else {
+ mark = wmark_pages(zone, alloc_flags & ALLOC_WMARK_MASK);
}
if (!zone_watermark_fast(zone, order, mark,
ac->highest_zoneidx, alloc_flags)) {
but that makes page_alloc.o 16 bytes larger, so I guess don't bother.

\
 
 \ /
  Last update: 2020-06-04 23:44    [W:0.090 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site