From: "Vlastimil Babka (SUSE)" <vbabka@kernel.org>
To: Christoph Hellwig <hch@infradead.org>,
changfengnan <changfengnan@bytedance.com>
Cc: Dave Chinner <david@fromorbit.com>,
Harry Yoo <harry.yoo@oracle.com>, Hao Li <hao.li@linux.dev>,
guzebing <guzebing1612@gmail.com>,
brauner@kernel.org, djwong@kernel.org, linux-xfs@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
guzebing@bytedance.com, syzbot@syzkaller.appspotmail.com,
linux-mm@kvack.org
Subject: Re: [PATCH v3] iomap: add allocation cache for iomap_dio
Date: Tue, 17 Mar 2026 10:21:08 +0100 [thread overview]
Message-ID: <aab8aebb-9703-4b6d-8ac6-e4811e972898@kernel.org> (raw)
In-Reply-To: <abkbE_zh79iCd5zs@infradead.org>
On 3/17/26 10:12, Christoph Hellwig wrote:
> On Tue, Mar 17, 2026 at 04:33:24PM +0800, changfengnan wrote:
>> > IO is not my area but getting from 1.19M to 1.20M doesn't look like it's
>> > worth the custom code? (possibly from 1.17M to 1.20M it also wasn't).
>> Yes, at least for now, there’s no need for a per-CPU.
>> It might be better to replace kmalloc with a new cache, but my tests so far
>> haven’t shown any performance improvements. I’ll look into it further.
>
> Does using a kmem_cache help? That should generally be a nice win
> anyway due to keeping the objects together.
I think that's exactly what "It might be better to replace kmalloc with a
new cache" meant, and apparently with no improvements.
You might want to try create it with SLAB_NO_MERGE flag so it's really a
separate cache. Custom sheaf_capacity might also achieve that effect, but in
order to have deterministic results, the flag is a sure way.
prev parent reply other threads:[~2026-03-17 9:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-15 2:11 [PATCH v3] iomap: add allocation cache for iomap_dio guzebing
2026-01-15 5:02 ` Dave Chinner
2026-03-16 11:22 ` changfengnan
2026-03-16 16:54 ` Vlastimil Babka (SUSE)
2026-03-17 7:28 ` changfengnan
2026-03-17 8:27 ` Vlastimil Babka (SUSE)
2026-03-17 8:33 ` changfengnan
2026-03-17 9:12 ` Christoph Hellwig
2026-03-17 9:19 ` changfengnan
2026-03-17 9:21 ` 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=aab8aebb-9703-4b6d-8ac6-e4811e972898@kernel.org \
--to=vbabka@kernel.org \
--cc=brauner@kernel.org \
--cc=changfengnan@bytedance.com \
--cc=david@fromorbit.com \
--cc=djwong@kernel.org \
--cc=guzebing1612@gmail.com \
--cc=guzebing@bytedance.com \
--cc=hao.li@linux.dev \
--cc=harry.yoo@oracle.com \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-xfs@vger.kernel.org \
--cc=syzbot@syzkaller.appspotmail.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.