From: Johannes Weiner <hannes@cmpxchg.org>
To: Yu Zhao <yuzhao@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Link Lin <linkl@google.com>, David Rientjes <rientjes@google.com>
Subject: Re: [PATCH mm-unstable v3] mm/page_alloc: keep track of free highatomic
Date: Tue, 29 Oct 2024 12:46:37 -0400 [thread overview]
Message-ID: <20241029164637.GA5108@cmpxchg.org> (raw)
In-Reply-To: <20241028182653.3420139-1-yuzhao@google.com>
On Mon, Oct 28, 2024 at 12:26:53PM -0600, Yu Zhao wrote:
> OOM kills due to vastly overestimated free highatomic reserves were
> observed:
>
> ... invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0 ...
> Node 0 Normal free:1482936kB boost:0kB min:410416kB low:739404kB high:1068392kB reserved_highatomic:1073152KB ...
> Node 0 Normal: 1292*4kB (ME) 1920*8kB (E) 383*16kB (UE) 220*32kB (ME) 340*64kB (E) 2155*128kB (UE) 3243*256kB (UE) 615*512kB (U) 1*1024kB (M) 0*2048kB 0*4096kB = 1477408kB
>
> The second line above shows that the OOM kill was due to the following
> condition:
>
> free (1482936kB) - reserved_highatomic (1073152kB) = 409784KB < min (410416kB)
>
> And the third line shows there were no free pages in any
> MIGRATE_HIGHATOMIC pageblocks, which otherwise would show up as type
> 'H'. Therefore __zone_watermark_unusable_free() underestimated the
> usable free memory by over 1GB, which resulted in the unnecessary OOM
> kill above.
>
> The comments in __zone_watermark_unusable_free() warns about the
> potential risk, i.e.,
>
> If the caller does not have rights to reserves below the min
> watermark then subtract the high-atomic reserves. This will
> over-estimate the size of the atomic reserve but it avoids a search.
>
> However, it is possible to keep track of free pages in reserved
> highatomic pageblocks with a new per-zone counter nr_free_highatomic
> protected by the zone lock, to avoid a search when calculating the
> usable free memory. And the cost would be minimal, i.e., simple
> arithmetics in the highatomic alloc/free/move paths.
>
> Note that since nr_free_highatomic can be relatively small, using a
> per-cpu counter might cause too much drift and defeat its purpose,
> in addition to the extra memory overhead.
>
> Reported-by: Link Lin <linkl@google.com>
> Signed-off-by: Yu Zhao <yuzhao@google.com>
> Acked-by: David Rientjes <rientjes@google.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
> @@ -642,6 +644,9 @@ static inline void account_freepages(struct zone *zone, int nr_pages,
>
> if (is_migrate_cma(migratetype))
> __mod_zone_page_state(zone, NR_FREE_CMA_PAGES, nr_pages);
> +
> + if (is_migrate_highatomic(migratetype))
> + WRITE_ONCE(zone->nr_free_highatomic, zone->nr_free_highatomic + nr_pages);
Minor nit, the page can only be of one migratetype, so `else if' would
be better.
next prev parent reply other threads:[~2024-10-29 16:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-28 18:26 [PATCH mm-unstable v3] mm/page_alloc: keep track of free highatomic Yu Zhao
2024-10-28 18:33 ` Vlastimil Babka
2024-10-29 16:46 ` Johannes Weiner [this message]
2024-10-29 16:49 ` Yu Zhao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241029164637.GA5108@cmpxchg.org \
--to=hannes@cmpxchg.org \
--cc=akpm@linux-foundation.org \
--cc=linkl@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rientjes@google.com \
--cc=vbabka@suse.cz \
--cc=yuzhao@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.