From: Matthew Wilcox <willy@infradead.org>
To: Ryan Roberts <ryan.roberts@arm.com>
Cc: Yang Shi <yang@os.amperecomputing.com>,
riel@surriel.com, shy828301@gmail.com, cl@linux.com,
akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [RESEND PATCH] mm: align larger anonymous mappings on THP boundaries
Date: Sat, 20 Jan 2024 16:39:44 +0000 [thread overview]
Message-ID: <Zav3UK7ESNxCMjyP@casper.infradead.org> (raw)
In-Reply-To: <1e8f5ac7-54ce-433a-ae53-81522b2320e1@arm.com>
On Sat, Jan 20, 2024 at 12:04:27PM +0000, Ryan Roberts wrote:
> However, after this patch, each allocation is in its own VMA, and there is a 2M
> gap between each VMA. This causes 2 problems: 1) mmap becomes MUCH slower
> because there are so many VMAs to check to find a new 1G gap. 2) It fails once
> it hits the VMA limit (/proc/sys/vm/max_map_count). Hitting this limit then
> causes a subsequent calloc() to fail, which causes the test to fail.
>
> Looking at the code, I think the problem is that arm64 selects
> ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT. But __thp_get_unmapped_area() allocates
> len+2M then always aligns to the bottom of the discovered gap. That causes the
> 2M hole. As far as I can see, x86 allocates bottom up, so you don't get a hole.
As a quick hack, perhaps
#ifdef ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT
take-the-top-half
#else
current-take-bottom-half-code
#endif
?
next prev parent reply other threads:[~2024-01-20 16:39 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-14 22:34 Yang Shi
2024-01-20 12:04 ` Ryan Roberts
2024-01-20 12:13 ` Ryan Roberts
2024-01-20 16:39 ` Matthew Wilcox [this message]
2024-01-22 11:37 ` Ryan Roberts
2024-01-22 19:43 ` Yang Shi
2024-01-23 9:41 ` Ryan Roberts
2024-01-23 17:14 ` Yang Shi
2024-01-23 17:26 ` Yang Shi
2024-01-23 17:26 ` Ryan Roberts
2024-01-23 17:33 ` Yang Shi
2024-05-07 8:25 ` Kefeng Wang
2024-05-07 10:08 ` Ryan Roberts
2024-05-07 10:59 ` Kefeng Wang
2024-05-07 11:13 ` David Hildenbrand
2024-05-07 11:14 ` Ryan Roberts
2024-05-07 11:26 ` Ryan Roberts
2024-05-07 11:34 ` David Hildenbrand
2024-05-07 11:42 ` David Hildenbrand
2024-05-07 12:36 ` Ryan Roberts
2024-05-07 13:53 ` Kefeng Wang
2024-05-07 15:53 ` Ryan Roberts
2024-05-07 17:17 ` Yang Shi
2024-05-08 7:48 ` Kefeng Wang
2024-05-08 8:36 ` Ryan Roberts
2024-05-08 13:37 ` Kefeng Wang
2024-05-08 13:41 ` Ryan Roberts
2024-05-08 15:25 ` Yang Shi
2024-05-09 1:47 ` Kefeng Wang
2024-01-22 20:20 ` Yang Shi
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=Zav3UK7ESNxCMjyP@casper.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=riel@surriel.com \
--cc=ryan.roberts@arm.com \
--cc=shy828301@gmail.com \
--cc=yang@os.amperecomputing.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