From: Andrew Morton <akpm@linux-foundation.org>
To: Frank van der Linden <fvdl@google.com>
Cc: linux-mm@kvack.org, muchun.song@linux.dev,
linux-kernel@vger.kernel.org,
Roman Gushchin <roman.gushchin@linux.dev>
Subject: Re: [PATCH 2/2] mm/hugetlb: pass correct order_per_bit to cma_declare_contiguous_nid
Date: Thu, 4 Apr 2024 13:17:34 -0700 [thread overview]
Message-ID: <20240404131734.5fdd7380202cafcdc44a4d2a@linux-foundation.org> (raw)
In-Reply-To: <20240404162515.527802-2-fvdl@google.com>
On Thu, 4 Apr 2024 16:25:15 +0000 Frank van der Linden <fvdl@google.com> wrote:
> The hugetlb_cma code passes 0 in the order_per_bit argument to
> cma_declare_contiguous_nid (the alignment, computed using the
> page order, is correctly passed in).
>
> This causes a bit in the cma allocation bitmap to always represent
> a 4k page, making the bitmaps potentially very large, and slower.
>
> So, correctly pass in the order instead.
Ditto. Should we backport this? Can we somewhat quantify "potentially very",
and understand under what circumstances this might occur?
next prev parent reply other threads:[~2024-04-04 20:17 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-04 16:25 [PATCH 1/2] mm/cma: drop incorrect alignment check in cma_init_reserved_mem Frank van der Linden
2024-04-04 16:25 ` [PATCH 2/2] mm/hugetlb: pass correct order_per_bit to cma_declare_contiguous_nid Frank van der Linden
2024-04-04 18:56 ` Roman Gushchin
2024-04-04 19:40 ` Frank van der Linden
2024-04-04 20:45 ` Roman Gushchin
2024-04-04 20:13 ` David Hildenbrand
2024-04-04 20:52 ` Roman Gushchin
2024-04-04 22:02 ` Frank van der Linden
2024-04-04 22:20 ` Andrew Morton
2024-04-04 21:44 ` Frank van der Linden
2024-04-04 22:22 ` Frank van der Linden
2024-04-08 8:15 ` David Hildenbrand
2024-04-04 20:17 ` Andrew Morton [this message]
2024-04-04 21:58 ` Frank van der Linden
2024-04-07 8:02 ` Muchun Song
2024-04-04 20:15 ` [PATCH 1/2] mm/cma: drop incorrect alignment check in cma_init_reserved_mem Andrew Morton
2024-04-04 20:45 ` Frank van der Linden
[not found] ` <93eccef7-a559-4ad8-be0f-8cc99c00bd09@redhat.com>
2024-04-04 20:48 ` Frank van der Linden
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=20240404131734.5fdd7380202cafcdc44a4d2a@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=fvdl@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=roman.gushchin@linux.dev \
/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