From: Andreas Hindborg <a.hindborg@kernel.org>
To: "Niklas Cassel" <cassel@kernel.org>
Cc: "Jan Kara" <jack@suse.cz>, <lsf-pc@lists.linux-foundation.org>,
<linux-block@vger.kernel.org>, "Jens Axboe" <axboe@kernel.dk>,
"Matthew Wilcox" <willy@infradead.org>,
"Luis Chamberlain" <mcgrof@kernel.org>,
"Miguel Ojeda" <ojeda@kernel.org>
Subject: Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Rust block layer abstractions and benchmark strategies
Date: Thu, 23 Jan 2025 09:56:20 +0100 [thread overview]
Message-ID: <87y0z1zz63.fsf@kernel.org> (raw)
In-Reply-To: <Z5C_1UmKQ1gSqlXQ@ryzen> (Niklas Cassel's message of "Wed, 22 Jan 2025 10:52:21 +0100")
"Niklas Cassel" <cassel@kernel.org> writes:
> Hello Andreas,
>
> On Tue, Jan 21, 2025 at 01:51:11PM +0100, Andreas Hindborg wrote:
>> Hi Jan,
>>
>> "Jan Kara" <jack@suse.cz> writes:
>>
>> > Hi!
>> >
>> > On Tue 21-01-25 12:13:48, Andreas Hindborg via Lsf-pc wrote:
>> >> I would like to propose that we have a session on Rust in the block
>> >> layer again this year. Specifically I would like to discuss some rather
>> >> puzzling results I observe when I benchmark the C and Rust null block
>> >> drivers. I did a write up of the challenges I face at [1]. The
>> >> observations are not tied to rust, they also manifest in the C driver.
>> >
>> > The results are indeed somewhat curious. One factor I didn't see addressed
>> > in your blog is CPU scheduling. I've seen in the past cases where IO tasks
>> > were getting migrated across cores leading to jumps in perfomance. Did you
>> > try binding fio jobs to one CPU each?
>>
>> Yes, I am pinning the io jobs to cores with fio options `cpus_allowed=0-<jobs>`
>> and `--cpus_allowed_policy=split` so I get 1 job per core.
>>
>> The kernel is configured with PREEMPT_NONE=y.
>
> "I also cover a problem with the benchmark results that manifested during
> testing for v6.12-rc2."
>
> I assume that all the results on:
> https://metaspace.github.io/2024/12/02/problems-in-benchmark-land.html
>
> are with kernel v6.12-rc2 ?
Yes.
>
> It would be interesting to test an older kernel version, and see if it
> is e.g. a scheduler bug.
Yes, I did not do that. I should collect some more detailed data for
past kernels.
> You might also want to test with this series applied (which landed last
> minute before v6.13 was tagged):
> https://lore.kernel.org/lkml/20250119110410.GAZ4zcKkx5sCjD5XvH@fat_crate.local/T/#u
>
>
> It fixes bugs that were introduced in v6.12-rc1 and v6.7-rc2 respectively.
>
I'll try that, thanks.
Best regards,
Andreas Hindborg
prev parent reply other threads:[~2025-01-23 8:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-21 11:13 [LSF/MM/BPF TOPIC] Rust block layer abstractions and benchmark strategies Andreas Hindborg
2025-01-21 12:04 ` [Lsf-pc] " Jan Kara
2025-01-21 12:51 ` Andreas Hindborg
2025-01-21 13:18 ` Jan Kara
2025-01-22 9:52 ` Niklas Cassel
2025-01-23 8:56 ` Andreas Hindborg [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=87y0z1zz63.fsf@kernel.org \
--to=a.hindborg@kernel.org \
--cc=axboe@kernel.dk \
--cc=cassel@kernel.org \
--cc=jack@suse.cz \
--cc=linux-block@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=mcgrof@kernel.org \
--cc=ojeda@kernel.org \
--cc=willy@infradead.org \
/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.