linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: akpm@linux-foundation.org, jbaron@akamai.com,
	kirill.shutemov@linux.intel.com, linux-mm@kvack.org,
	mhocko@suse.com, mm-commits@vger.kernel.org, opendmb@gmail.com,
	rientjes@google.com, stable@vger.kernel.org,
	torvalds@linux-foundation.org
Subject: [patch 10/11] mm: include CMA pages in lowmem_reserve at boot
Date: Thu, 20 Aug 2020 17:42:24 -0700	[thread overview]
Message-ID: <20200821004224.7O8mn8lhd%akpm@linux-foundation.org> (raw)
In-Reply-To: <20200820174132.67fd4a7a9359048f807a533b@linux-foundation.org>

From: Doug Berger <opendmb@gmail.com>
Subject: mm: include CMA pages in lowmem_reserve at boot

The lowmem_reserve arrays provide a means of applying pressure against
allocations from lower zones that were targeted at higher zones.  Its
values are a function of the number of pages managed by higher zones and
are assigned by a call to the setup_per_zone_lowmem_reserve() function.

The function is initially called at boot time by the function
init_per_zone_wmark_min() and may be called later by accesses of the
/proc/sys/vm/lowmem_reserve_ratio sysctl file.

The function init_per_zone_wmark_min() was moved up from a module_init to
a core_initcall to resolve a sequencing issue with khugepaged. 
Unfortunately this created a sequencing issue with CMA page accounting.

The CMA pages are added to the managed page count of a zone when
cma_init_reserved_areas() is called at boot also as a core_initcall.  This
makes it uncertain whether the CMA pages will be added to the managed page
counts of their zones before or after the call to
init_per_zone_wmark_min() as it becomes dependent on link order.  With the
current link order the pages are added to the managed count after the
lowmem_reserve arrays are initialized at boot.

This means the lowmem_reserve values at boot may be lower than the values
used later if /proc/sys/vm/lowmem_reserve_ratio is accessed even if the
ratio values are unchanged.

In many cases the difference is not significant, but for example
an ARM platform with 1GB of memory and the following memory layout
[    0.000000] cma: Reserved 256 MiB at 0x0000000030000000
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000000000000-0x000000002fffffff]
[    0.000000]   Normal   empty
[    0.000000]   HighMem  [mem 0x0000000030000000-0x000000003fffffff]

would result in 0 lowmem_reserve for the DMA zone.  This would allow
userspace to deplete the DMA zone easily.  Funnily enough

$ cat /proc/sys/vm/lowmem_reserve_ratio

would fix up the situation because it forces setup_per_zone_lowmem_reserve
as a side effect.

This commit breaks the link order dependency by invoking
init_per_zone_wmark_min() as a postcore_initcall so that the CMA pages
have the chance to be properly accounted in their zone(s) and allowing the
lowmem_reserve arrays to receive consistent values.

Link: http://lkml.kernel.org/r/1597423766-27849-1-git-send-email-opendmb@gmail.com
Fixes: bc22af74f271 ("mm: update min_free_kbytes from khugepaged after core initialization")
Signed-off-by: Doug Berger <opendmb@gmail.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Jason Baron <jbaron@akamai.com>
Cc: David Rientjes <rientjes@google.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 mm/page_alloc.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/mm/page_alloc.c~mm-include-cma-pages-in-lowmem_reserve-at-boot
+++ a/mm/page_alloc.c
@@ -7888,7 +7888,7 @@ int __meminit init_per_zone_wmark_min(vo
 
 	return 0;
 }
-core_initcall(init_per_zone_wmark_min)
+postcore_initcall(init_per_zone_wmark_min)
 
 /*
  * min_free_kbytes_sysctl_handler - just a wrapper around proc_dointvec() so
_


  parent reply	other threads:[~2020-08-21  0:42 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-21  0:41 incoming Andrew Morton
2020-08-21  0:41 ` [patch 01/11] mailmap: add Andi Kleen Andrew Morton
2020-08-21  0:41 ` [patch 02/11] hugetlb_cgroup: convert comma to semicolon Andrew Morton
2020-08-21  0:42 ` [patch 03/11] khugepaged: adjust VM_BUG_ON_MM() in __khugepaged_enter() Andrew Morton
2020-08-21  0:42 ` [patch 04/11] mm/vunmap: add cond_resched() in vunmap_pmd_range Andrew Morton
2020-08-21  0:42 ` [patch 05/11] mm/rodata_test.c: fix missing function declaration Andrew Morton
2020-08-21  0:42 ` [patch 06/11] romfs: fix uninitialized memory leak in romfs_dev_read() Andrew Morton
2020-08-21  0:42 ` [patch 07/11] kernel/relay.c: fix memleak on destroy relay channel Andrew Morton
2020-08-21  0:42 ` [patch 08/11] uprobes: __replace_page() avoid BUG in munlock_vma_page() Andrew Morton
2020-08-21  0:42 ` [patch 09/11] squashfs: avoid bio_alloc() failure with 1Mbyte blocks Andrew Morton
2020-08-21  0:42 ` Andrew Morton [this message]
2020-08-21  0:42 ` [patch 11/11] mm, page_alloc: fix core hung in free_pcppages_bulk() Andrew Morton

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=20200821004224.7O8mn8lhd%akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=jbaron@akamai.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=mm-commits@vger.kernel.org \
    --cc=opendmb@gmail.com \
    --cc=rientjes@google.com \
    --cc=stable@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).