mirror of https://lore.kernel.org/lkml/
 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: Tue, 3 Mar 2026 14:28:47 +0100	[thread overview]
Message-ID: <cba02030-752e-43e1-9f65-8b726c4d42fb@rocketmail.com> (raw)
In-Reply-To: <20260303013309.GB6520@macsyma-wired.lan>



On 03. 03. 2026. 02:33, Theodore Tso wrote:
> On Mon, Mar 02, 2026 at 09:04:44PM +0100, Mario Lohajner wrote:
>> RRALLOC spreads allocation starting points across block groups to avoid
>> repeated concentration under parallel load.
> 
> There are already other ways in which we spread allocations across
> block groups.  You need to tell explain a specific workload where this
> actually makes a difference.
> 
> Also note that in most use cases, files are written once, and read
> multiple times.  So spreading blocks across different block groups is
> can often be actively harmful.
> 
>> In high-concurrency testing, performance is consistently comparable to
>> or occasionally better than the regular allocator. No regressions have
>> been observed across tested configurations.
> 
> No regressions, and only "occasionally better" not enough of a justifiation.
> 
> What is your real life workload which is motivating your efforts?
> 
>       	     	       		      	 - Ted

RRALLOC targets sustained parallel overwrite-heavy workloads such as
scratch disks, rendering outputs, database storage and VM image storage.

It introduces a round-robin allocation policy across block groups to
reduce short-term allocation concentration under high concurrency.

It is not intended to improve write-once/read-many workloads and remains
disabled by default.

I do understand that without clearly measurable workload-specific 
improvement, this is likely not sufficient justification for upstream 
inclusion.

I will continue evaluating and refining the allocator out-of-tree.
If I am able to demonstrate concrete and reproducible benefits beyond
allocation geometry and occasional contention-related effects,
I will revisit the discussion with additional data.

Thank you for the review and valuable feedback.

Regards,
Mario Lohajner

  reply	other threads:[~2026-03-03 13:49 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 ` 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
2026-03-03  1:33                 ` Theodore Tso
2026-03-03 13:28                   ` Mario Lohajner [this message]
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=cba02030-752e-43e1-9f65-8b726c4d42fb@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

all inboxes | Powered by JetHome®