public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mario Lohajner <mario_lohajner@rocketmail.com>
To: Theodore Tso <tytso@mit.edu>
Cc: Andreas Dilger <adilger@dilger.ca>,
	libaokun1@huawei.com, adilger.kernel@dilger.ca,
	linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org,
	yangerkun@huawei.com, libaokun9@gmail.com
Subject: Re: [PATCH] ext4: rralloc - (former rotalloc) improved round-robin allocation policy
Date: Mon, 2 Mar 2026 21:04:44 +0100	[thread overview]
Message-ID: <c156caec-e2c8-4b85-a135-0adecb56a859@rocketmail.com> (raw)
In-Reply-To: <20260227164319.GB93969@macsyma-wired.lan>



On 27. 02. 2026. 17:43, Theodore Tso wrote:
> On Fri, Feb 27, 2026 at 03:46:59PM +0100, Mario Lohajner wrote:
>>
>> Concentrated allocation can create contention, write amplification, and
>> uneven LBA utilization even on modern NVMe/SSD devices.
> 
> Uneven LBA utilization is the thing where I'm asking, "why should we care".
> 
> In terms of how this would cause contention and write amplification,
> <<citation needed>>.  What is your benchmarks where you can
> demonstrate this, and how common is this across NVMe/SSD devices?
> That is, if it's just one trashy product, maybe it should just be
> avoided --- especially if it has other problems.
> 
> 						- Ted

RRALLOC spreads allocation starting points across block groups to avoid
repeated concentration under parallel load.

This reduces short-term allocation concentration in the same regions
when multiple CPUs allocate concurrently.

In high-concurrency testing, performance is consistently comparable to
or occasionally better than the regular allocator. No regressions have
been observed across tested configurations.

Under sustained parallel allocation pressure, testing shows improved
tail-latency stability compared to the current allocator.

Additional high-concurrency test results are available at:
https://github.com/mlohajner/RRALLOC

Regards,
Mario Lohajner

  reply	other threads:[~2026-03-02 20:04 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260225201520.220071-1-mario_lohajner.ref@rocketmail.com>
2026-02-25 20:15 ` [PATCH] ext4: rralloc - (former rotalloc) improved round-robin allocation policy Mario Lohajner
2026-02-25 23:49   ` Andreas Dilger
2026-02-26  2:48     ` Theodore Tso
2026-02-26 21:50       ` Mario Lohajner
2026-02-27  1:12         ` Theodore Tso
2026-02-27 14:46           ` Mario Lohajner
2026-02-27 16:43             ` Theodore Tso
2026-03-02 20:04               ` Mario Lohajner [this message]
2026-03-03  1:33                 ` Theodore Tso
2026-03-03 13:28                   ` Mario Lohajner
2026-03-05  2:47                     ` Theodore Tso

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=c156caec-e2c8-4b85-a135-0adecb56a859@rocketmail.com \
    --to=mario_lohajner@rocketmail.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=adilger@dilger.ca \
    --cc=libaokun1@huawei.com \
    --cc=libaokun9@gmail.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.edu \
    --cc=yangerkun@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox