From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sonic317-32.consmr.mail.ne1.yahoo.com (sonic317-32.consmr.mail.ne1.yahoo.com [66.163.184.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2F8683F0767 for ; Fri, 27 Feb 2026 15:07:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=66.163.184.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772204841; cv=none; b=XNe/YKZlmJ/HfY0qkoZiYTdqpm+hJu6w2wf/HWO4/XUafmxVUfSN8LWjy7JVCp/lmPFXEoz9eNLuI7AVSWxSnHnNhmkasv2GUTblwiQqOpR0AEhaHE4ZSnARA5CDDHIwJ1gcdPj+gM7+QrNFLcTpC+545iuSVYM571O5Tx8sdVk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772204841; c=relaxed/simple; bh=RapVb7BH+XK2subqtHq2u+14TIv+lNVtbIvsVoDVLEA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=HG6qV8jjo3LwKUDA+pPhyHivoV4Mh4V+R1+OZPOMpA0we++OKRUSpX1JeHh+ArTR5PM8/ywI2njoV2cofaCFiCAuy3nicMRDXQoneRIBOZD/97ucncEOoSGZPvyOOXQdlot/h9J4yXnHcZ4o5Y++Mo60hGryhmvLhAo019XfjHQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=rocketmail.com; spf=pass smtp.mailfrom=rocketmail.com; dkim=pass (2048-bit key) header.d=rocketmail.com header.i=@rocketmail.com header.b=PH5Axea6; arc=none smtp.client-ip=66.163.184.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=rocketmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rocketmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rocketmail.com header.i=@rocketmail.com header.b="PH5Axea6" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rocketmail.com; s=s2048; t=1772204839; bh=XoZFibiMoK98Hdn2fiBFquvQMiQpEw8kJwSX6qSl8sY=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From:Subject:Reply-To; b=PH5Axea6/VHZtpgtrBnY4Pez+hW0nKB8oHqOXa68NTTj7k5s5UpFeASz08tw8TxnrinWSHi3liRQZ7vDP8Di5bFoQIUx0s2mV7afZXJmXmPsgyKSliK3U3jhz49jWlNH5h9OkmOoa2GtSarlff6v/YP6571JdezCJVjziRb+XY/Sguo57JRU9uxnDsbhPwrKEbjXNMeurmOoUqpVyGG8CzMRRCZytNJvzReuenqSUdDdIQtPnhyVNGhP4bkKZ5w2K9FE1s3cSrQkEOjd3ZcgC93f2SguceEuWDkzNLAI29a37Bh3Rti2N3ZAtrZH8hf09JCRnn/B9MfQgEsjMYz7Uw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1772204839; bh=C/jTwZeodwTAfNlyuVWwiS1vS27E2jqcLC/ZuaEX8qo=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=MEu5wHkUWf7uEYveaNjxGSaX0JucZk/1QGJrZKuXsFEiBC0TCbE2VMEo9GN+TYSj6OzN4NkgcPMy2rrHOE0S3nXkzfbTh/O/I1mNdxo3/kOhrpvdT9u05GgO+SmHRbxrrgl3YA8YE17whmWmceORlyob5gVqazZXf9iyUx4MuKLz3a0jks5CnYhFxsm9B++gJYjKTfPBPUa8anQwv4x0E7N1a78feAGjbv/bdeTLA8rThJCNu5edD97ijtQ1WzCC9Fu81jia/DhXfn59tC2GGfF7kB0P7g/bFiIRxCMPxmNw/fIcWXVLZOL806dbNgyxe9atqOFNwIBQIQkG9naXpA== X-YMail-OSG: gWEZVU8VM1leEryLpFUuj_5y23J90XoEuIIcEd3jswva5uCxblPeS3gizBaKDOD 53KZgIPUCFuQLtoW48TMIIyT3_1N8nWJEI60PrUOMm.e0P3R8SbIMrUL99g9skMrrFBQhg_xgdCO ggBH8T4eOjvgPvTZWLDqUxNUQvYvfWETlqmZg_8.w3dvjQqngPt.KsvUHRH_pDds8wB9qVYz4Hmz CkvqDCYMTgPk6HA9EzBYhB2ueS.mJb.BrjVh1f3JG5vMAm61a3aI9kIxX43kmGxXzmOtZNT3kprw sX2Qeui8IoiKaQCpxBWWmp5SoPf44FmGvzcB7iqajwOeUiMtm1j2yWeOANl9DaUZrLmgk_Fwfv_N ukwobtd_R0nYF8P08H5usPhhsAiH50P.XfiDS8mwLPcT.sIMpp1OQF6b1hXAxL43EN0.6lbCDMbR p8eFRfDDYZ78N8JfWALkwBjG5UKIp0GPkbSHBrGEBAlnFaJ4p0DcCoPTWW8Oc6uHe2LZ6LajdMNY ndpzKwUmdfJXMf3sEiYIQWpEhOboBgVKwD._jkF2pmKzMUMoX0DnukvU0f.ZEMKUA6MjMO8szpey 2HHZcfIUXhoon435j2Px2SXrWiirB6dYfluZDFP0tWpJAQCxH36b3QGIFcN8n9CtcsPGAmS_OeQ. r6YxrbEkqTKr_jzSFbOH4ua_yfnE74NkuPHH6eANECoKA72d7vMoy7tm2_ep7gm0.oZTLCcwuT78 AN713iW56GR123qabTzNpnK5pCzDbArnKumBUu4xkJgdqkhz9QhBHWEblwuZ7Wte1MZBhWut9NkT H_cckAcJmIznluDSM3Eu5CJsodDUjTWmSHLdf.Ou6JPeI9MjDO5Hc5B3cLlypeDX6d8zg8FzccxJ .I7Vql7KjgJWl0gOMV351MkK.kRpxl_NDro8NmWTp_s9LmIJtekvcRgEFU7jspDntYZVvfkbTvJ_ mnGjzvPx0LX0oRk2qPS4KbbGCB4OGEpjj1S3tR812lA_AAAiPjjWNH8vWh1DI.z0gImmjT2jJKyc Vt8wa98J7TEYodBIEOyOTegDIwpzJIsgkn8m6g4MbAAi6u4TcOtMfSlQCnNmhZCa35TbzeZHH_HP .9p49FPIP2txbYme2lBAySqY6tjampx73Ml8gWW.A66p1h87C.aw86N6jsf44I7jZN7QH_EMyF3X Q89we6UYN37BHm9_pzhFg_1XogIfN.csavVPObZI6TOZHbBMAfvaGiokJv5gB32xZqJxBK5KiLVB M12Po8RrWV4MqGcYRQK9JXe3sZNX1R9VAH_D7gk2Pj.SS8asVA_u09Zek1LwKgnQI5QNrjPcj2JC ETIUeH5nEH3xpkodeqjgHSKH_A4HIBgP4YGK6PJOsFE0cqUo8fuI7ujojC1H.7q9OS.b9._RVyEm L_lG0AxCon5unhKOGAGVjnRXRA8aC20oGx.CPxxi.AEvfszNjMONZ0FSdXe915npW6.zpDgOs.x2 X6.7vQO3dfh2iEuCWnn4nQZngKtwUiiVjDs4DQYOywNDWOjbSjb3jNCVLBXTGjY5mQBVSw7AKhho ir64fC3bbMUg1zvijrRnohPLPJw3JOMK6luMG1H7b1U4yAkq.lrlXyaL_BCGa4eODlEph3FK2bui 8abEgS_mboN2RERZIp2TCPEbW3sxZo7lq2jC5Srvv2A2q0ybwiGt20grZ41Bv2e2cwlkR8T8WxlE BKsV7M1Psb5ln4Hl7OwGnXQ8nyB6HD5uiUaayRxffSuKoe82xW4_Oqp9Pw2DRvTMN4LEre3Sc2y6 3jYeH9zuwj_ROSv.Qyb6wd.8pc6d_klBi3AkRKsu99yAlPGYrl4znVGL02713x29z89aHMmU3BKD 6WVe5FBek01WPPgJF4bQ0QEzs6Jh9R7VwvRfI62lDMKS9G7ucCJhA9LPdGDa_Vkbx6Py9eBmaiP_ OAyQRloyS_G9ESyeFknWenG.Qz4qKtFYFHKX_B7_z3yfEaCOwvU7dsDdrvMmbO.lAhQHE8AznC34 1vpBQLlEjgKV2u0ZKtWTrD61XaivIjUrIcB0.HZ3GwhPHlNlwXZ39xN_4nR6Ipniz5plTNCxHbgG zTS3ammJBS.BAeOlN8tEl5VwAX_.SW_09WBvMf2YstbXdfgN80U5XW.XqsQiZLpxFMDXZ1jouZ.x 1As1mQP7hW9wDPbdPGtLl4d49LyK.XqdKgT67kPo2FMjFthHPkp_xvHZ.xgsSxrO8xhjH_p_p3DG gqtintjeMWnhHdZdhqsa_OGbZ_IB5R2tAbqJaOOSoZqVq X-Sonic-MF: X-Sonic-ID: c4899a92-95ad-4936-a571-bd6653b366a3 Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.ne1.yahoo.com with HTTP; Fri, 27 Feb 2026 15:07:19 +0000 Received: by hermes--production-ir2-bbcfb4457-w955t (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f278db9c2cba741c058b044e6ad65a2d; Fri, 27 Feb 2026 14:47:01 +0000 (UTC) Message-ID: <2af6328d-5a72-476d-9768-9398a9417ea6@rocketmail.com> Date: Fri, 27 Feb 2026 15:46:59 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] ext4: rralloc - (former rotalloc) improved round-robin allocation policy To: Theodore Tso Cc: Andreas Dilger , libaokun1@huawei.com, adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, yangerkun@huawei.com, libaokun9@gmail.com References: <20260225201520.220071-1-mario_lohajner.ref@rocketmail.com> <20260225201520.220071-1-mario_lohajner@rocketmail.com> <20260226024819.GA39209@macsyma-wired.lan> <04dfeda0-8c13-4233-b631-d8912d4fe6f0@rocketmail.com> <20260227011200.GA68551@macsyma-wired.lan> Content-Language: hr From: Mario Lohajner In-Reply-To: <20260227011200.GA68551@macsyma-wired.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.25198 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo 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)