From: Roman Gushchin <guro@fb.com>
To: Wonhyuk Yang <vvghjk1234@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Mike Rapoport <rppt@kernel.org>, <linux-mm@kvack.org>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Rik van Riel <riel@surriel.com>, Michal Hocko <mhocko@kernel.org>,
<linux-kernel@vger.kernel.org>, <kernel-team@fb.com>
Subject: Re: [PATCH v2 2/2] memblock: do not start bottom-up allocations with kernel_end
Date: Sat, 19 Dec 2020 09:05:35 -0800 [thread overview]
Message-ID: <20201219170535.GA3428478@carbon.DHCP.thefacebook.com> (raw)
In-Reply-To: <CAEcHRTqcrEdXcr02OZnSTgxwQ0Por7y4gAXn6uM=Dp=TVq_5kA@mail.gmail.com>
On Sat, Dec 19, 2020 at 11:52:19PM +0900, Wonhyuk Yang wrote:
> Hi Roman,
>
> On Fri, Dec 18, 2020 at 5:12 AM Roman Gushchin <guro@fb.com> wrote:
> >
> > With kaslr the kernel image is placed at a random place, so starting
> > the bottom-up allocation with the kernel_end can result in an
> > allocation failure and a warning like this one:
> >
> > [ 0.002920] hugetlb_cma: reserve 2048 MiB, up to 2048 MiB per node
> > [ 0.002921] ------------[ cut here ]------------
> > [ 0.002922] memblock: bottom-up allocation failed, memory hotremove may be affected
> > [ 0.002937] WARNING: CPU: 0 PID: 0 at mm/memblock.c:332 memblock_find_in_range_node+0x178/0x25a
> > [ 0.002956] Call Trace:
> > [ 0.002961] ? memblock_alloc_range_nid+0x8d/0x11e
> > [ 0.002963] ? cma_declare_contiguous_nid+0x2c4/0x38c
> > [ 0.002964] ? hugetlb_cma_reserve+0xdc/0x128
> > [ 0.002968] ? flush_tlb_one_kernel+0xc/0x20
> > [ 0.002969] ? native_set_fixmap+0x82/0xd0
> > [ 0.002971] ? flat_get_apic_id+0x5/0x10
> > [ 0.002973] ? register_lapic_address+0x8e/0x97
> > [ 0.002975] ? setup_arch+0x8a5/0xc3f
> > [ 0.002978] ? start_kernel+0x66/0x547
> > [ 0.002980] ? load_ucode_bsp+0x4c/0xcd
> > [ 0.002982] ? secondary_startup_64_no_verify+0xb0/0xbb
> > [ 0.002986] random: get_random_bytes called from __warn+0xab/0x110 with crng_init=0
> >
> > At the same time, the kernel image is protected with memblock_reserve(),
> > so we can just start searching at PAGE_SIZE. In this case the
> > bottom-up allocation has the same chances to success as a top-down
> > allocation, so there is no reason to fallback in the case of a
> > failure. All together it simplifies the logic.
>
> I figure out that it was introduced by
> commit 79442ed189acb ("memblock.c: introduce bottom-up allocation mode")
>
> According to this commit, The purpose of bottom up allocation is to
> allocate memory from the unhotpluggable node.
Hi Wonhyuk,
correct! And it remains this way, we just don't need to skip
all the memory before the kernel_end.
Thanks!
next prev parent reply other threads:[~2020-12-19 17:05 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-17 20:12 [PATCH v2 1/2] mm: cma: allocate cma areas bottom-up Roman Gushchin
2020-12-17 20:12 ` [PATCH v2 2/2] memblock: do not start bottom-up allocations with kernel_end Roman Gushchin
2020-12-19 14:52 ` Wonhyuk Yang
2020-12-19 17:05 ` Roman Gushchin [this message]
2020-12-20 6:49 ` Mike Rapoport
2021-01-22 4:37 ` Thiago Jung Bauermann
2021-01-24 2:09 ` Andrew Morton
2021-01-24 7:34 ` Mike Rapoport
2021-01-26 0:30 ` Thiago Jung Bauermann
2021-02-08 23:58 ` Thiago Jung Bauermann
2021-02-28 4:18 ` Florian Fainelli
2021-02-28 9:00 ` Mike Rapoport
2021-02-28 18:19 ` Florian Fainelli
2021-02-28 23:08 ` Serge Semin
2021-03-01 3:50 ` Florian Fainelli
2021-03-01 9:22 ` Serge Semin
2021-03-02 4:09 ` Florian Fainelli
2021-03-01 9:45 ` Mike Rapoport
2021-03-02 3:55 ` Roman Gushchin
2020-12-20 6:48 ` [PATCH v2 1/2] mm: cma: allocate cma areas bottom-up Mike Rapoport
2020-12-21 17:05 ` Roman Gushchin
2020-12-23 4:06 ` Andrew Morton
2020-12-23 16:35 ` Roman Gushchin
2020-12-23 22:10 ` Mike Rapoport
2020-12-28 19:36 ` Roman Gushchin
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=20201219170535.GA3428478@carbon.DHCP.thefacebook.com \
--to=guro@fb.com \
--cc=akpm@linux-foundation.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=riel@surriel.com \
--cc=rppt@kernel.org \
--cc=vvghjk1234@gmail.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 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).