lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <5e02a1fb-8fdf-4523-8f51-9bcacfa74f1a@huawei.com> Date: Tue, 1 Jul 2025 20:12:49 +0800 From: Baokun Li <libaokun1@...wei.com> To: Jan Kara <jack@...e.cz> CC: <linux-ext4@...r.kernel.org>, <tytso@....edu>, <adilger.kernel@...ger.ca>, <ojaswin@...ux.ibm.com>, <linux-kernel@...r.kernel.org>, <yi.zhang@...wei.com>, <yangerkun@...wei.com>, Baokun Li <libaokun1@...wei.com> Subject: Re: [PATCH v2 04/16] ext4: utilize multiple global goals to reduce contention On 2025/7/1 19:53, Jan Kara wrote: > On Tue 01-07-25 11:32:23, Baokun Li wrote: >> On 2025/7/1 1:41, Jan Kara wrote: >>> On Mon 30-06-25 18:02:49, Baokun Li wrote: >>>> On 2025/6/30 16:38, Jan Kara wrote: >>>>> We could make streaming goal to be ext4_fsblk_t so that also offset of the >>>>> last big allocation in the group is recorded as I wrote above. That would >>>>> tend to pack big allocations in each group together which is benefitial to >>>>> combat fragmentation even with higher proportion of groups that are streaming >>>>> goals (and likely becomes more important as the blocksize and thus group >>>>> size grow). We can discuss proper number of slots for streaming allocation >>>>> (I'm not hung up on it being quarter of the group count) but I'm convinced >>>>> sb->s_groups_count is too much :) >>>>> >>>>> Honza >>>> I think sbi->s_groups_count / 4 is indeed acceptable. However, I don't >>>> believe recording offsets is necessary. As groups become larger, >>>> contention for groups will intensify, and adding offsets would only >>>> make this contention worse. >>> I agree the contention for groups will increase when the group count goes >>> down. I just thought offsets may help to find free space faster in large >>> groups (and thus reduce contention) and also reduce free space >>> fragmentation within a group (by having higher chances of placing large >>> allocations close together within a group) but maybe that's not the case. >>> Offsets are definitely not requirement at this point. >>> >>> Honza >>> >> Thinking this over, with LBS support coming, if our block size jumps from >> 4KB to 64KB, the maximum group size will dramatically increase from 128MB >> to 32GB (even with the current 4GB group limit). If free space within a >> group gets heavily fragmented, iterating through that single group could >> become quite time-consuming. >> >> Your idea of recording offsets to prevent redundant scanning of >> already-checked extents within a group definitely makes sense. But with >> reference to the idea of optimizing linear traversal of groups, I think it >> might be better to record the offset of the first occurrence of each order >> in the same way that bb_counters records the number of each order. > Yes, something like that makes sense. But I guess that's a material for the > next patch set :) > > Honza Yes, this isn't urgent right now. I plan to implement this idea after the LBS patch set is complete. Thank you very much for your review and patient explanations! 😀 Regards, Baokun
Powered by blists - more mailing lists