From: Ross Zwisler <zwisler@google.com>
To: Mike Rapoport <rppt@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Andrew Morton <akpm@linux-foundation.org>,
Matthew Wilcox <willy@infradead.org>,
Mel Gorman <mgorman@suse.de>, Michal Hocko <mhocko@kernel.org>,
Vlastimil Babka <vbabka@suse.cz>,
David Hildenbrand <david@redhat.com>
Subject: Re: collision between ZONE_MOVABLE and memblock allocations
Date: Wed, 19 Jul 2023 16:26:04 -0600 [thread overview]
Message-ID: <20230719222604.GB3528218@google.com> (raw)
In-Reply-To: <20230719054434.GG1901145@kernel.org>
On Wed, Jul 19, 2023 at 08:44:34AM +0300, Mike Rapoport wrote:
> 3. Switch memblock to use bottom up allocations. Historically memblock
> allocated memory from the top to avoid corrupting the kernel image and to
> avoid exhausting precious ZONE_DMA. I believe we can use bottom-up
> allocations with lower limit of memblock allocations set to 16M.
>
> With the hack below no memblock allocations will end up in ZONE_MOVABLE:
Yep, I've confirmed that for my use cases at least this does the trick, thank
you! I had thought about moving the memblock allocations, but had no idea it
was (basically) already supported and thought it'd be much riskier than just
adjusting where ZONE_MOVABLE lived.
Is there a reason for this to not be a real option for users, maybe per a
kernel config knob or something? I'm happy to explore other options in this
thread, but this is doing the trick so far.
next prev parent reply other threads:[~2023-07-19 22:26 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-18 22:01 collision between ZONE_MOVABLE and memblock allocations Ross Zwisler
2023-07-19 5:44 ` Mike Rapoport
2023-07-19 22:26 ` Ross Zwisler [this message]
2023-07-21 11:20 ` Mike Rapoport
2023-07-26 7:49 ` Michal Hocko
2023-07-26 10:48 ` Mike Rapoport
2023-07-26 12:57 ` Michal Hocko
2023-07-26 13:23 ` Mike Rapoport
2023-07-26 14:23 ` Michal Hocko
2023-07-19 6:14 ` Michal Hocko
2023-07-19 7:59 ` Mike Rapoport
2023-07-19 8:06 ` Michal Hocko
2023-07-19 8:14 ` David Hildenbrand
2023-07-19 23:05 ` Ross Zwisler
2023-07-26 8:31 ` David Hildenbrand
2023-07-19 22:48 ` Ross Zwisler
2023-07-20 7:49 ` Michal Hocko
2023-07-20 12:13 ` Michal Hocko
2023-07-24 16:56 ` Ross Zwisler
2023-07-26 8:44 ` David Hildenbrand
2023-07-26 13:08 ` David Hildenbrand
2023-07-27 8:18 ` Michal Hocko
2023-07-27 9:41 ` David Hildenbrand
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=20230719222604.GB3528218@google.com \
--to=zwisler@google.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@kernel.org \
--cc=rppt@kernel.org \
--cc=vbabka@suse.cz \
--cc=willy@infradead.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 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.