Commit 1c30844d2dfe ("mm: reclaim small amounts of memory when an external
fragmentation event occurs") adds a boost_watermark() function which
increases the min watermark in a zone by at least pageblock_nr_pages or
the number of pages in a page block. On Arm64, with 64K pages and 512M
huge pages, this is 8192 pages or 512M. It does this regardless of the
number of managed pages managed in the zone or the likelihood of success.
This can put the zone immediately under water in terms of allocating pages
from the zone, and can cause a small machine to fail immediately due to
OoM. Unlike set_recommended_min_free_kbytes(), which substantially
increases min_free_kbytes and is tied to THP, boost_watermark() can be
called even if THP is not active. The problem is most likely to appear
on architectures such as Arm64 where pageblock_nr_pages is very large.
It is desirable to run the kdump capture kernel in as small a space as
possible to avoid wasting memory. In some architectures, such as Arm64,
there are restrictions on where the capture kernel can run, and therefore,
the space available. A capture kernel running in 768M can fail due to OoM
immediately after boost_watermark() sets the min in zone DMA32, where
most of the memory is, to 512M. It fails even though there is over 500M of
free memory. With boost_watermark() suppressed, the capture kernel can run
successfully in 448M.
This patch limits boost_watermark() to boosting a zone's min watermark only
when there are enough pages that the boost will produce positive results.
In this case that is estimated to be four times as many pages as
pageblock_nr_pages.
Signed-off-by: Henry Willard <[email protected]>
---
mm/page_alloc.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 69827d4fa052..67805e794660 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2400,6 +2400,14 @@ static inline void boost_watermark(struct zone *zone)
if (!watermark_boost_factor)
return;
+ /*
+ * Don't bother in zones that are unlikely to produce results.
+ * On small machines, including kdump capture kernels running
+ * in a small area, boosting the watermark can cause an out of
+ * memory situation immediately.
+ */
+ if ((pageblock_nr_pages * 4) > zone_managed_pages(zone))
+ return;
max_boost = mult_frac(zone->_watermark[WMARK_HIGH],
watermark_boost_factor, 10000);
--
1.8.3.1
On Thu, 30 Apr 2020 17:49:08 -0700 Henry Willard <[email protected]> wrote:
> Commit 1c30844d2dfe ("mm: reclaim small amounts of memory when an external
> fragmentation event occurs") adds a boost_watermark() function which
> increases the min watermark in a zone by at least pageblock_nr_pages or
> the number of pages in a page block. On Arm64, with 64K pages and 512M
> huge pages, this is 8192 pages or 512M. It does this regardless of the
> number of managed pages managed in the zone or the likelihood of success.
> This can put the zone immediately under water in terms of allocating pages
> from the zone, and can cause a small machine to fail immediately due to
> OoM. Unlike set_recommended_min_free_kbytes(), which substantially
> increases min_free_kbytes and is tied to THP, boost_watermark() can be
> called even if THP is not active. The problem is most likely to appear
> on architectures such as Arm64 where pageblock_nr_pages is very large.
>
> It is desirable to run the kdump capture kernel in as small a space as
> possible to avoid wasting memory. In some architectures, such as Arm64,
> there are restrictions on where the capture kernel can run, and therefore,
> the space available. A capture kernel running in 768M can fail due to OoM
> immediately after boost_watermark() sets the min in zone DMA32, where
> most of the memory is, to 512M. It fails even though there is over 500M of
> free memory. With boost_watermark() suppressed, the capture kernel can run
> successfully in 448M.
>
> This patch limits boost_watermark() to boosting a zone's min watermark only
> when there are enough pages that the boost will produce positive results.
> In this case that is estimated to be four times as many pages as
> pageblock_nr_pages.
>
Let's Cc Mel.
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -2400,6 +2400,14 @@ static inline void boost_watermark(struct zone *zone)
>
> if (!watermark_boost_factor)
> return;
> + /*
> + * Don't bother in zones that are unlikely to produce results.
> + * On small machines, including kdump capture kernels running
> + * in a small area, boosting the watermark can cause an out of
> + * memory situation immediately.
> + */
> + if ((pageblock_nr_pages * 4) > zone_managed_pages(zone))
> + return;
>
> max_boost = mult_frac(zone->_watermark[WMARK_HIGH],
> watermark_boost_factor, 10000);
> --
> 1.8.3.1
On Fri, May 01, 2020 at 03:57:29PM -0700, Andrew Morton wrote:
> On Thu, 30 Apr 2020 17:49:08 -0700 Henry Willard <[email protected]> wrote:
>
> > Commit 1c30844d2dfe ("mm: reclaim small amounts of memory when an external
> > fragmentation event occurs") adds a boost_watermark() function which
> > increases the min watermark in a zone by at least pageblock_nr_pages or
> > the number of pages in a page block. On Arm64, with 64K pages and 512M
> > huge pages, this is 8192 pages or 512M. It does this regardless of the
> > number of managed pages managed in the zone or the likelihood of success.
> > This can put the zone immediately under water in terms of allocating pages
> > from the zone, and can cause a small machine to fail immediately due to
> > OoM. Unlike set_recommended_min_free_kbytes(), which substantially
> > increases min_free_kbytes and is tied to THP, boost_watermark() can be
> > called even if THP is not active. The problem is most likely to appear
> > on architectures such as Arm64 where pageblock_nr_pages is very large.
> >
> > It is desirable to run the kdump capture kernel in as small a space as
> > possible to avoid wasting memory. In some architectures, such as Arm64,
> > there are restrictions on where the capture kernel can run, and therefore,
> > the space available. A capture kernel running in 768M can fail due to OoM
> > immediately after boost_watermark() sets the min in zone DMA32, where
> > most of the memory is, to 512M. It fails even though there is over 500M of
> > free memory. With boost_watermark() suppressed, the capture kernel can run
> > successfully in 448M.
> >
> > This patch limits boost_watermark() to boosting a zone's min watermark only
> > when there are enough pages that the boost will produce positive results.
> > In this case that is estimated to be four times as many pages as
> > pageblock_nr_pages.
> >
>
> Let's Cc Mel.
>
Seems reasonable.
Acked-by: Mel Gorman <[email protected]>
--
Mel Gorman
SUSE Labs
On Mon, 4 May 2020 13:44:09 +0100 Mel Gorman <[email protected]> wrote:
> On Fri, May 01, 2020 at 03:57:29PM -0700, Andrew Morton wrote:
> > On Thu, 30 Apr 2020 17:49:08 -0700 Henry Willard <[email protected]> wrote:
> >
> > > Commit 1c30844d2dfe ("mm: reclaim small amounts of memory when an external
> > > fragmentation event occurs") adds a boost_watermark() function which
> > > increases the min watermark in a zone by at least pageblock_nr_pages or
> > > the number of pages in a page block. On Arm64, with 64K pages and 512M
> > > huge pages, this is 8192 pages or 512M. It does this regardless of the
> > > number of managed pages managed in the zone or the likelihood of success.
> > > This can put the zone immediately under water in terms of allocating pages
> > > from the zone, and can cause a small machine to fail immediately due to
> > > OoM. Unlike set_recommended_min_free_kbytes(), which substantially
> > > increases min_free_kbytes and is tied to THP, boost_watermark() can be
> > > called even if THP is not active. The problem is most likely to appear
> > > on architectures such as Arm64 where pageblock_nr_pages is very large.
> > >
> > > It is desirable to run the kdump capture kernel in as small a space as
> > > possible to avoid wasting memory. In some architectures, such as Arm64,
> > > there are restrictions on where the capture kernel can run, and therefore,
> > > the space available. A capture kernel running in 768M can fail due to OoM
> > > immediately after boost_watermark() sets the min in zone DMA32, where
> > > most of the memory is, to 512M. It fails even though there is over 500M of
> > > free memory. With boost_watermark() suppressed, the capture kernel can run
> > > successfully in 448M.
> > >
> > > This patch limits boost_watermark() to boosting a zone's min watermark only
> > > when there are enough pages that the boost will produce positive results.
> > > In this case that is estimated to be four times as many pages as
> > > pageblock_nr_pages.
> > >
> >
> ...
> Acked-by: Mel Gorman <[email protected]>
Cool. I wonder if we should backport this into -stable kernels? "can
cause a small machine to fail immediately" sounds serious, but
1c30844d2dfe is from December 2018. Any thoughts?
On 5/4/20 1:36 PM, Andrew Morton wrote:
> On Mon, 4 May 2020 13:44:09 +0100 Mel Gorman <[email protected]> wrote:
>
>> On Fri, May 01, 2020 at 03:57:29PM -0700, Andrew Morton wrote:
>>> On Thu, 30 Apr 2020 17:49:08 -0700 Henry Willard <[email protected]> wrote:
>>>
>>>> Commit 1c30844d2dfe ("mm: reclaim small amounts of memory when an external
>>>> fragmentation event occurs") adds a boost_watermark() function which
>>>> increases the min watermark in a zone by at least pageblock_nr_pages or
>>>> the number of pages in a page block. On Arm64, with 64K pages and 512M
>>>> huge pages, this is 8192 pages or 512M. It does this regardless of the
>>>> number of managed pages managed in the zone or the likelihood of success.
>>>> This can put the zone immediately under water in terms of allocating pages
>>>> from the zone, and can cause a small machine to fail immediately due to
>>>> OoM. Unlike set_recommended_min_free_kbytes(), which substantially
>>>> increases min_free_kbytes and is tied to THP, boost_watermark() can be
>>>> called even if THP is not active. The problem is most likely to appear
>>>> on architectures such as Arm64 where pageblock_nr_pages is very large.
>>>>
>>>> It is desirable to run the kdump capture kernel in as small a space as
>>>> possible to avoid wasting memory. In some architectures, such as Arm64,
>>>> there are restrictions on where the capture kernel can run, and therefore,
>>>> the space available. A capture kernel running in 768M can fail due to OoM
>>>> immediately after boost_watermark() sets the min in zone DMA32, where
>>>> most of the memory is, to 512M. It fails even though there is over 500M of
>>>> free memory. With boost_watermark() suppressed, the capture kernel can run
>>>> successfully in 448M.
>>>>
>>>> This patch limits boost_watermark() to boosting a zone's min watermark only
>>>> when there are enough pages that the boost will produce positive results.
>>>> In this case that is estimated to be four times as many pages as
>>>> pageblock_nr_pages.
>>>>
>> ...
>> Acked-by: Mel Gorman <[email protected]>
> Cool. I wonder if we should backport this into -stable kernels? "can
> cause a small machine to fail immediately" sounds serious, but
> 1c30844d2dfe is from December 2018. Any thoughts?
It is a trivial patch, and we always like to have them in -stable
kernels when possible. It was a serious problem for us, because we had a
configuration where kdump on Arm always failed. However, other than
kdump, the problem is probably relatively rare.
Thanks,
Henry
On Mon, May 04, 2020 at 01:36:04PM -0700, Andrew Morton wrote:
> On Mon, 4 May 2020 13:44:09 +0100 Mel Gorman <[email protected]> wrote:
>
> > On Fri, May 01, 2020 at 03:57:29PM -0700, Andrew Morton wrote:
> > > On Thu, 30 Apr 2020 17:49:08 -0700 Henry Willard <[email protected]> wrote:
> > >
> > > > Commit 1c30844d2dfe ("mm: reclaim small amounts of memory when an external
> > > > fragmentation event occurs") adds a boost_watermark() function which
> > > > increases the min watermark in a zone by at least pageblock_nr_pages or
> > > > the number of pages in a page block. On Arm64, with 64K pages and 512M
> > > > huge pages, this is 8192 pages or 512M. It does this regardless of the
> > > > number of managed pages managed in the zone or the likelihood of success.
> > > > This can put the zone immediately under water in terms of allocating pages
> > > > from the zone, and can cause a small machine to fail immediately due to
> > > > OoM. Unlike set_recommended_min_free_kbytes(), which substantially
> > > > increases min_free_kbytes and is tied to THP, boost_watermark() can be
> > > > called even if THP is not active. The problem is most likely to appear
> > > > on architectures such as Arm64 where pageblock_nr_pages is very large.
> > > >
> > > > It is desirable to run the kdump capture kernel in as small a space as
> > > > possible to avoid wasting memory. In some architectures, such as Arm64,
> > > > there are restrictions on where the capture kernel can run, and therefore,
> > > > the space available. A capture kernel running in 768M can fail due to OoM
> > > > immediately after boost_watermark() sets the min in zone DMA32, where
> > > > most of the memory is, to 512M. It fails even though there is over 500M of
> > > > free memory. With boost_watermark() suppressed, the capture kernel can run
> > > > successfully in 448M.
> > > >
> > > > This patch limits boost_watermark() to boosting a zone's min watermark only
> > > > when there are enough pages that the boost will produce positive results.
> > > > In this case that is estimated to be four times as many pages as
> > > > pageblock_nr_pages.
> > > >
> > >
> > ...
> > Acked-by: Mel Gorman <[email protected]>
>
> Cool. I wonder if we should backport this into -stable kernels? "can
> cause a small machine to fail immediately" sounds serious, but
> 1c30844d2dfe is from December 2018. Any thoughts?
There is no harm in marking it stable. Clearly it does not happen very
often but it's not impossible. 32-bit x86 is a lot less common now which
would previously have been vulnerable to triggering this easily. ppc64
has a larger base page size but typically only has one zone. arm64 is
likely the most vulnerable, particularly when CMA is configured with a
small movable zone.
--
Mel Gorman
SUSE Labs
On 01.05.20 02:49, Henry Willard wrote:
> Commit 1c30844d2dfe ("mm: reclaim small amounts of memory when an external
> fragmentation event occurs") adds a boost_watermark() function which
> increases the min watermark in a zone by at least pageblock_nr_pages or
> the number of pages in a page block. On Arm64, with 64K pages and 512M
> huge pages, this is 8192 pages or 512M. It does this regardless of the
> number of managed pages managed in the zone or the likelihood of success.
> This can put the zone immediately under water in terms of allocating pages
> from the zone, and can cause a small machine to fail immediately due to
> OoM. Unlike set_recommended_min_free_kbytes(), which substantially
> increases min_free_kbytes and is tied to THP, boost_watermark() can be
> called even if THP is not active. The problem is most likely to appear
> on architectures such as Arm64 where pageblock_nr_pages is very large.
>
> It is desirable to run the kdump capture kernel in as small a space as
> possible to avoid wasting memory. In some architectures, such as Arm64,
> there are restrictions on where the capture kernel can run, and therefore,
> the space available. A capture kernel running in 768M can fail due to OoM
> immediately after boost_watermark() sets the min in zone DMA32, where
> most of the memory is, to 512M. It fails even though there is over 500M of
> free memory. With boost_watermark() suppressed, the capture kernel can run
> successfully in 448M.
>
> This patch limits boost_watermark() to boosting a zone's min watermark only
> when there are enough pages that the boost will produce positive results.
> In this case that is estimated to be four times as many pages as
> pageblock_nr_pages.
>
> Signed-off-by: Henry Willard <[email protected]>
Reviewed-by: David Hildenbrand <[email protected]>
--
Thanks,
David / dhildenb