All of lore.kernel.org
 help / color / mirror / Atom feed
From: Niklas Cassel <cassel@kernel.org>
To: Andreas Hindborg <a.hindborg@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: Wed, 22 Jan 2025 10:52:21 +0100	[thread overview]
Message-ID: <Z5C_1UmKQ1gSqlXQ@ryzen> (raw)
In-Reply-To: <87sepcba9s.fsf@kernel.org>

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 ?

It would be interesting to test an older kernel version, and see if it
is e.g. a scheduler bug.


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.


Kind regards,
Niklas

  parent reply	other threads:[~2025-01-22  9:52 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 [this message]
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=Z5C_1UmKQ1gSqlXQ@ryzen \
    --to=cassel@kernel.org \
    --cc=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.