From: Andreas Hindborg <a.hindborg@kernel.org>
To: "Jan Kara" <jack@suse.cz>
Cc: <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: Tue, 21 Jan 2025 13:51:11 +0100 [thread overview]
Message-ID: <87sepcba9s.fsf@kernel.org> (raw)
In-Reply-To: <w4gsgpfgz335cvyjjk5oaykl3wav7d2q4robxuw73pqkkxznlx@hgap3lzl3vbs> (Jan Kara's message of "Tue, 21 Jan 2025 13:04:30 +0100")
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.
Best regards,
Andreas Hindborg
next prev parent reply other threads:[~2025-01-21 12:51 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 [this message]
2025-01-21 13:18 ` Jan Kara
2025-01-22 9:52 ` Niklas Cassel
2025-01-23 8:56 ` Andreas Hindborg
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=87sepcba9s.fsf@kernel.org \
--to=a.hindborg@kernel.org \
--cc=axboe@kernel.dk \
--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.