From: "Vlastimil Babka (SUSE)" <vbabka@kernel.org>
To: Christoph Hellwig <hch@lst.de>,
harry@kernel.org, akpm@linux-foundation.org
Cc: hao.li@linux.dev, cl@gentwo.org, rientjes@google.com,
roman.gushchin@linux.dev, linux-block@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH] mm: simplify the mempool_alloc_bulk API
Date: Wed, 3 Jun 2026 11:41:48 +0200 [thread overview]
Message-ID: <64fff44b-27ae-4943-a199-d8764dc28f80@kernel.org> (raw)
In-Reply-To: <20260602160038.3976341-1-hch@lst.de>
On 6/2/26 18:00, Christoph Hellwig wrote:
> The mempool_alloc_bulk was modelled after the alloc_pages_bulk API,
> including some misunderstanding of it.
>
> Remove checking for NULL slots in the array, as alloc_pages_bulk and
> kmem_cache_alloc_bulk always fill the array from the beginning and thus
> we know the offset of the first failing allocation. This removes support
> for working well with alloc_pages_bulk used to refill page arrays that
> might have an entry removed from in the middle, but that is only used by
> sunrpc and hopefully on it's way out.
Importantly sunrpc doesn't use mempool_alloc_bulk() so we're not affecting
it here.
> Also remove the allocated parameter as it is redundant because the caller
> can simply specific and offset into the entries array.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Somewhat late, but small and affects only one caller. So applied to
slab/for-7.2/alloc_bulk on top of the kmem_cache_alloc_bulk() change.
> ---
> block/blk-crypto-fallback.c | 9 +++++----
> include/linux/mempool.h | 2 +-
> mm/mempool.c | 27 ++++++++++-----------------
> 3 files changed, 16 insertions(+), 22 deletions(-)
>
> diff --git a/block/blk-crypto-fallback.c b/block/blk-crypto-fallback.c
> index 61f595410832..ab6924fba280 100644
> --- a/block/blk-crypto-fallback.c
> +++ b/block/blk-crypto-fallback.c
> @@ -199,8 +199,8 @@ static struct bio *blk_crypto_alloc_enc_bio(struct bio *bio_src,
> pages += nr_segs * (PAGE_PTRS_PER_BVEC - 1);
>
> /*
> - * Try a bulk allocation first. This could leave random pages in the
> - * array unallocated, but we'll fix that up later in mempool_alloc_bulk.
> + * Try a bulk allocation first. This might not fill all allocated
> + * pages, but we'll fix that up later in mempool_alloc_bulk.
> *
> * Note: alloc_pages_bulk needs the array to be zeroed, as it assumes
> * any non-zero slot already contains a valid allocation.
> @@ -208,8 +208,9 @@ static struct bio *blk_crypto_alloc_enc_bio(struct bio *bio_src,
> memset(pages, 0, sizeof(struct page *) * nr_segs);
> nr_allocated = alloc_pages_bulk(GFP_KERNEL, nr_segs, pages);
> if (nr_allocated < nr_segs)
> - mempool_alloc_bulk(blk_crypto_bounce_page_pool, (void **)pages,
> - nr_segs, nr_allocated);
> + mempool_alloc_bulk(blk_crypto_bounce_page_pool,
> + (void **)pages + nr_allocated,
> + nr_segs - nr_allocated);
> memalloc_noio_restore(memflags);
> *pages_ret = pages;
> return bio;
> diff --git a/include/linux/mempool.h b/include/linux/mempool.h
> index e8e440e04a06..a0fa6d43e0dc 100644
> --- a/include/linux/mempool.h
> +++ b/include/linux/mempool.h
> @@ -66,7 +66,7 @@ void *mempool_alloc_noprof(struct mempool *pool, gfp_t gfp_mask) __malloc;
> #define mempool_alloc(...) \
> alloc_hooks(mempool_alloc_noprof(__VA_ARGS__))
> int mempool_alloc_bulk_noprof(struct mempool *pool, void **elem,
> - unsigned int count, unsigned int allocated);
> + unsigned int count);
> #define mempool_alloc_bulk(...) \
> alloc_hooks(mempool_alloc_bulk_noprof(__VA_ARGS__))
>
> diff --git a/mm/mempool.c b/mm/mempool.c
> index db23e0eef652..473a029fa31f 100644
> --- a/mm/mempool.c
> +++ b/mm/mempool.c
> @@ -419,12 +419,8 @@ static unsigned int mempool_alloc_from_pool(struct mempool *pool, void **elems,
> spin_lock_irqsave(&pool->lock, flags);
> if (unlikely(pool->curr_nr < count - allocated))
> goto fail;
> - for (i = 0; i < count; i++) {
> - if (!elems[i]) {
> - elems[i] = remove_element(pool);
> - allocated++;
> - }
> - }
> + while (allocated < count)
> + elems[allocated++] = remove_element(pool);
> spin_unlock_irqrestore(&pool->lock, flags);
>
> /* Paired with rmb in mempool_free(), read comment there. */
> @@ -479,22 +475,21 @@ static inline gfp_t mempool_adjust_gfp(gfp_t *gfp_mask)
> * @pool: pointer to the memory pool
> * @elems: partially or fully populated elements array
> * @count: number of entries in @elem that need to be allocated
> - * @allocated: number of entries in @elem already allocated
> *
> - * Allocate elements for each slot in @elem that is non-%NULL. This is done by
> - * first calling into the alloc_fn supplied at pool initialization time, and
> - * dipping into the reserved pool when alloc_fn fails to allocate an element.
> + * Allocate @count elements into @elems. This is done by first calling into the
> + * alloc_fn supplied at pool initialization time, and dipping into the reserved
> + * pool when alloc_fn fails to allocate an element.
> *
> * On return all @count elements in @elems will be populated.
> *
> * Return: Always 0. If it wasn't for %$#^$ alloc tags, it would return void.
> */
> int mempool_alloc_bulk_noprof(struct mempool *pool, void **elems,
> - unsigned int count, unsigned int allocated)
> + unsigned int count)
> {
> gfp_t gfp_mask = GFP_KERNEL;
> gfp_t gfp_temp = mempool_adjust_gfp(&gfp_mask);
> - unsigned int i = 0;
> + unsigned int allocated = 0;
>
> VM_WARN_ON_ONCE(count > pool->min_nr);
> might_alloc(gfp_mask);
> @@ -514,11 +509,9 @@ int mempool_alloc_bulk_noprof(struct mempool *pool, void **elems,
> * Try to allocate the elements using the allocation callback first as
> * that might succeed even when the caller's bulk allocation did not.
> */
> - for (i = 0; i < count; i++) {
> - if (elems[i])
> - continue;
> - elems[i] = pool->alloc(gfp_temp, pool->pool_data);
> - if (unlikely(!elems[i]))
> + while (allocated < count) {
> + elems[allocated] = pool->alloc(gfp_temp, pool->pool_data);
> + if (unlikely(!elems[allocated]))
> goto use_pool;
> allocated++;
> }
prev parent reply other threads:[~2026-06-03 9:41 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-02 16:00 [PATCH] mm: simplify the mempool_alloc_bulk API Christoph Hellwig
2026-06-03 9:41 ` Vlastimil Babka (SUSE) [this message]
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=64fff44b-27ae-4943-a199-d8764dc28f80@kernel.org \
--to=vbabka@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=cl@gentwo.org \
--cc=hao.li@linux.dev \
--cc=harry@kernel.org \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rientjes@google.com \
--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