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: Fri, 27 Feb 2026 15:46:59 +0100 [thread overview]
Message-ID: <2af6328d-5a72-476d-9768-9398a9417ea6@rocketmail.com> (raw)
In-Reply-To: <20260227011200.GA68551@macsyma-wired.lan>
On 27. 02. 2026. 02:12, Theodore Tso wrote:
> On Thu, Feb 26, 2026 at 10:50:29PM +0100, Mario Lohajner wrote:
>> The primary purpose of rralloc is to improve allocation distribution
>> and avoid hotspotting. Performance improvements are not the goal here...
>
> You haven't explained *why* allocation distribution and avoiding
> hotspotting is something we should care about.
>
> If it's not performance, then why? How does reducing hotspotting
> improve things for the user? Why should we care about this goal that
> apparently is so important to you?
>
> - Ted
Hello Ted,
The motivation behind rralloc is to promote even allocation across the
available LBA under overwrite-heavy workloads.
With the regular allocator, repeated allocations can concentrate the
pressure in specific regions (e.g., in-place overwrites or LBA start).
rralloc spreads allocations across the LBA, reducing localized
contention while:
* promoting existing stream allocation behavior
* distributing LBA space per CPU
* preserving intra-file locality and heuristics
* using the entire LBA in a round-robin manner
* minimizing contention and races
* keeping the regular allocator isolated and intact
Block group usage analysis confirms that rralloc distributes
allocations evenly without degrading baseline throughput:
* small/medium/large file fragmentation experiments
* synthetic tests
* real-world tests (kernel source tree copies)
https://github.com/mlohajner/RRALLOC
Why it matters:
Concentrated allocation can create contention, write amplification, and
uneven LBA utilization even on modern NVMe/SSD devices.
rralloc promotes round-robin allocation across the entire LBA,
with per-CPU zones, ensuring more even allocation distribution while
leaving throughput and existing heuristics unchanged.
Workloads include (but not limited to):
* media files processing and rendering
* builds/compilations
* database workloads
End user impact:
Users can enable rralloc at mount to take advantage of this alternative
allocation policy.
Regular allocator behavior remains unchanged for those who prefer linear
or traditional allocation.
This approach is backward-compatible, non-intrusive, and preserves
on-disk format and existing heuristics.
Preliminary observations under heavy multi-threaded workloads suggest
reduced contention effects, but this has not yet been fully characterized.
Regards,
Mario Lohajner (manjo)
next prev parent reply other threads:[~2026-02-27 15:07 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 [this message]
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
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=2af6328d-5a72-476d-9768-9398a9417ea6@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®