From: Damien Le Moal <dlemoal@kernel.org>
To: Vitaly Wool <vitaly.wool@konsulko.se>, Christoph Hellwig <hch@lst.de>
Cc: Harry Yoo <harry@kernel.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Roman Gushchin <roman.gushchin@linux.dev>,
David Rientjes <rientjes@google.com>,
Christoph Lameter <cl@gentwo.org>, Hao Li <hao.li@linux.dev>,
Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@kernel.org>,
vitaly.vul@partner.samsung.com
Subject: Re: [PATCH] mempool: optimize mempool resizing
Date: Mon, 19 Oct 2026 11:40:53 +0200 [thread overview]
Message-ID: <2546936e-1ae6-494f-a3e8-1949436bfd3a@kernel.org> (raw)
In-Reply-To: <20261017090802.1423681-1-vitaly.wool@konsulko.se>
On 2026/10/17 11:08, Vitaly Wool wrote:
>>> Imagine you have a mempool with 10000 elements, and you have to reduce it to 3000. Then
>>> if you at some point want to go back to 10000, you'll end up reallocating the elements
>
>> Who is "we" and where is the code? This is a highly unusual, not to
>> say most like broken usage of mempools. If you need changes to support
>> such a use case you should include a link to the intree user (or bundle
>> it with the submission of the new code).
>
> This situation may well happen in the block layer (zoned). The numbers will
> be different but they were arbitrarily chosen in the example above anyway.
The block layer zoned code does not use gigantic buffers from a mempool. The
mempool is only used for small zone write plugs descriptors and if the user goes
over the device advertized max open limit, using lots of plugs, the device perf
will start going to /dev/null. So optimizing for growing the mempool for this
case is really not a priority/needed, at all.
--
Damien Le Moal
Western Digital Research
prev parent reply other threads:[~2026-10-19 9:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-13 9:14 [PATCH v2] " Vitaly Wool
2026-10-13 11:49 ` Harry Yoo
2026-10-14 8:45 ` Re: [PATCH] " Vitaly Wool
2026-10-14 13:03 ` Christoph Hellwig
2026-10-17 9:08 ` Vitaly Wool
2026-10-19 9:40 ` Damien Le Moal [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=2546936e-1ae6-494f-a3e8-1949436bfd3a@kernel.org \
--to=dlemoal@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-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=vbabka@kernel.org \
--cc=vitaly.vul@partner.samsung.com \
--cc=vitaly.wool@konsulko.se \
/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
all inboxes | Powered by JetHome®