From: Usama Arif <usamaarif642@gmail.com>
To: Yosry Ahmed <yosryahmed@google.com>, Hugh Dickins <hughd@google.com>
Cc: kernel test robot <oliver.sang@intel.com>,
oe-lkp@lists.linux.dev, lkp@intel.com,
Linux Memory Management List <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>,
Chengming Zhou <chengming.zhou@linux.dev>,
Nhat Pham <nphamcs@gmail.com>,
David Hildenbrand <david@redhat.com>,
"Huang, Ying" <ying.huang@intel.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Matthew Wilcox <willy@infradead.org>,
Shakeel Butt <shakeel.butt@linux.dev>,
Andi Kleen <ak@linux.intel.com>,
linux-kernel@vger.kernel.org,
"Vlastimil Babka (SUSE)" <vbabka@kernel.org>,
Yury Norov <yury.norov@gmail.com>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>
Subject: Re: [linux-next:master] [mm] 0fa2857d23: WARNING:at_mm/page_alloc.c:#__alloc_pages_noprof
Date: Mon, 24 Jun 2024 20:26:39 +0300 [thread overview]
Message-ID: <cacd14a9-01fc-4844-9ac6-2e797af13c36@gmail.com> (raw)
In-Reply-To: <CAJD7tkYJVa=dd=hwqhJ8_-uzxFDaP6-GcTk3RdG_3DJouJ61AQ@mail.gmail.com>
On 24/06/2024 19:56, Yosry Ahmed wrote:
> [..]
>>>> - p->zeromap = bitmap_zalloc(maxpages, GFP_KERNEL);
>>>> + p->zeromap = kvzalloc(DIV_ROUND_UP(maxpages, 8), GFP_KERNEL);
>>> No, 8 is not right for 32-bit kernels. I think you want
>>> p->zeromap = kvzalloc(BITS_TO_LONGS(maxpages), GFP_KERNEL);
>>> but please check it carefully, I'm easily confused by such conversions.
>>>
>>> Hugh
>> Ah yes, didnt take into account 32-bit kernel. I think its supposed to be
>>
>> p->zeromap = kvzalloc(BITS_TO_LONGS(maxpages) * sizeof(unsigned long),
>> GFP_KERNEL);
> You can do something similar to bitmap_zalloc() and use:
>
> kvmalloc_array(BITS_TO_LONGS(nbits), sizeof(unsigned long), GFP_KERNEL
> | __GFP_ZERO)
>
> I don't see a kvzalloc_array() variant to use directly, but it should
> be trivial to add it. I can see other users of kvmalloc_array() that
> pass in __GFP_ZERO (e.g. fs/ntfs3/bitmap.c).
>
> , or you could take it a step further and add bitmap_kvzalloc(),
> assuming the maintainers are open to that.
Thanks! bitmap_kvzalloc makes most sense to me. It doesnt make sense
that bitmap should only be limited to MAX_PAGE_ORDER size. I can add
this patch below at the start of the series and use it in the patch for
zeropage swap optimization.
bitmap: add support for virtually contiguous bitmap
The current bitmap_zalloc API limits the allocation to MAX_PAGE_ORDER,
which prevents larger order bitmap allocations. Introduce
bitmap_kvzalloc that will allow larger allocations of bitmap.
kvmalloc_array still attempts to allocate physically contiguous memory,
but upon failure, falls back to non-contiguous (vmalloc) allocation.
Suggested-by: Yosry Ahmed <yosryahmed@google.com>
Signed-off-by: Usama Arif <usamaarif642@gmail.com>
diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index 8c4768c44a01..881c2ff2e834 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -131,9 +131,11 @@ struct device;
*/
unsigned long *bitmap_alloc(unsigned int nbits, gfp_t flags);
unsigned long *bitmap_zalloc(unsigned int nbits, gfp_t flags);
+unsigned long *bitmap_kvzalloc(unsigned int nbits, gfp_t flags);
unsigned long *bitmap_alloc_node(unsigned int nbits, gfp_t flags, int
node);
unsigned long *bitmap_zalloc_node(unsigned int nbits, gfp_t flags, int
node);
void bitmap_free(const unsigned long *bitmap);
+void bitmap_kvfree(const unsigned long *bitmap);
DEFINE_FREE(bitmap, unsigned long *, if (_T) bitmap_free(_T))
diff --git a/lib/bitmap.c b/lib/bitmap.c
index b97692854966..eabbfb85fb45 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -727,6 +727,13 @@ unsigned long *bitmap_zalloc(unsigned int nbits,
gfp_t flags)
}
EXPORT_SYMBOL(bitmap_zalloc);
+unsigned long *bitmap_kvzalloc(unsigned int nbits, gfp_t flags)
+{
+ return kvmalloc_array(BITS_TO_LONGS(nbits), sizeof(unsigned long),
+ flags | __GFP_ZERO);
+}
+EXPORT_SYMBOL(bitmap_zalloc);
+
unsigned long *bitmap_alloc_node(unsigned int nbits, gfp_t flags, int
node)
{
return kmalloc_array_node(BITS_TO_LONGS(nbits), sizeof(unsigned
long),
@@ -746,6 +753,12 @@ void bitmap_free(const unsigned long *bitmap)
}
EXPORT_SYMBOL(bitmap_free);
+void bitmap_kvfree(const unsigned long *bitmap)
+{
+ kvfree(bitmap);
+}
+EXPORT_SYMBOL(bitmap_kvfree);
+
static void devm_bitmap_free(void *data)
{
unsigned long *bitmap = data;
>
> The main reason I want to avoid doing the multiplication inline is
> because kvmalloc_array() has a check_mul_overflow() check, and I
> assume it must have been added for a reason.
next prev parent reply other threads:[~2024-06-24 17:26 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-24 8:49 [linux-next:master] [mm] 0fa2857d23: WARNING:at_mm/page_alloc.c:#__alloc_pages_noprof kernel test robot
2024-06-24 12:05 ` Yosry Ahmed
2024-06-24 13:06 ` Usama Arif
2024-06-24 15:26 ` Hugh Dickins
2024-06-24 15:39 ` Usama Arif
2024-06-24 15:55 ` Hugh Dickins
2024-06-24 16:56 ` Yosry Ahmed
2024-06-24 17:26 ` Usama Arif [this message]
2024-06-24 17:31 ` Yosry Ahmed
2024-06-24 18:26 ` Usama Arif
2024-06-27 11:05 ` Usama Arif
2024-06-24 18:33 ` Matthew Wilcox
2024-06-24 18:50 ` Usama Arif
2024-06-24 18:53 ` Yosry Ahmed
2024-06-24 18:54 ` Matthew Wilcox
2024-06-24 18:53 ` Yosry Ahmed
2024-06-24 18:56 ` Matthew Wilcox
2024-06-24 18:57 ` Yosry Ahmed
2024-06-24 19:26 ` Matthew Wilcox
2024-06-24 19:34 ` Yosry Ahmed
2024-06-24 19:50 ` Matthew Wilcox
2024-06-24 20:39 ` Shakeel Butt
2024-06-24 20:51 ` Matthew Wilcox
2024-06-24 21:02 ` Shakeel Butt
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=cacd14a9-01fc-4844-9ac6-2e797af13c36@gmail.com \
--to=usamaarif642@gmail.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=chengming.zhou@linux.dev \
--cc=david@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@rasmusvillemoes.dk \
--cc=lkp@intel.com \
--cc=nphamcs@gmail.com \
--cc=oe-lkp@lists.linux.dev \
--cc=oliver.sang@intel.com \
--cc=shakeel.butt@linux.dev \
--cc=vbabka@kernel.org \
--cc=willy@infradead.org \
--cc=ying.huang@intel.com \
--cc=yosryahmed@google.com \
--cc=yury.norov@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 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.