From nobody Sun Dec 14 12:13:21 2025 Received: from dggsgout11.his.huawei.com (dggsgout11.his.huawei.com [45.249.212.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EF388223702; Fri, 23 May 2025 09:03:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.51 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747990998; cv=none; b=jUMLhdkCLmim3/TbQjm+ADi9YTP2/1N22/0bsC+BnibC8IribFSih/BmydxNTLSAZ2i74zFXHqSnuvQkjF7+mYQ9EHoQYIkgtVeI++4uh4V9w/VcIoXKIUUg5UQDEka14eqNfXYpRmjmeobNgANMMtsGcYn30rI+Ee3pgmkBy7A= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747990998; c=relaxed/simple; bh=J3SxiOMpPZbohVP3HSSPnrrxas0MoAU8ASSoVi9x3+E=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=dkZOX6CaviON03RT9qmnEvPYZ8Ep8y5+4T4jwq05U6LZ73XJwtOMRqIIhRA12sP+t94RzvpfzZMVQg0gMqnpfqB2A6ta/4xMuT97dvo98FkohIYBEkFjaVse9xLeR3boJH64KWjXfOc03PUorkQ7i5XvGAXHtNxsbwySGFad7eA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.93.142]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTP id 4b3fLz2cvnz4f3jt8; Fri, 23 May 2025 17:02:51 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id 4D2A01A018D; Fri, 23 May 2025 17:03:11 +0800 (CST) Received: from huaweicloud.com (unknown [10.175.104.67]) by APP4 (Coremail) with SMTP id gCh0CgCH61_MOTBocBILNQ--.27999S5; Fri, 23 May 2025 17:03:11 +0800 (CST) From: libaokun@huaweicloud.com To: linux-ext4@vger.kernel.org Cc: tytso@mit.edu, adilger.kernel@dilger.ca, jack@suse.cz, linux-kernel@vger.kernel.org, yi.zhang@huawei.com, yangerkun@huawei.com, libaokun1@huawei.com, libaokun@huaweicloud.com Subject: [PATCH 1/4] ext4: add ext4_try_lock_group() to skip busy groups Date: Fri, 23 May 2025 16:58:18 +0800 Message-Id: <20250523085821.1329392-2-libaokun@huaweicloud.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20250523085821.1329392-1-libaokun@huaweicloud.com> References: <20250523085821.1329392-1-libaokun@huaweicloud.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: gCh0CgCH61_MOTBocBILNQ--.27999S5 X-Coremail-Antispam: 1UD129KBjvJXoWxCrWDWr1UZry5WrW3XryUGFg_yoW7GryUpw srZ3Z8Ar45Wwn8uws7G3y0qw4Fkw40gFWUJrWfuw17Zry3Xrna9as7tF17AF9FgFs3JFnx X3Wav3y7Cr13u37anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUPv14x267AKxVW5JVWrJwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_Jr4l82xGYIkIc2 x26xkF7I0E14v26r1I6r4UM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2z4x0 Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJw A2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq3wAS 0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2 IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0 Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwAKzVCY07xG64k0F24lc7CjxV Aaw2AFwI0_Jw0_GFyl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2Iq xVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r 1q6r43MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY 6xkF7I0E14v26r4j6F4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67 AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyTuY vjfUegAzUUUUU X-CM-SenderInfo: 5olet0hnxqqx5xdzvxpfor3voofrz/1tbiAgARBWgwLIYF3AAAs9 Content-Type: text/plain; charset="utf-8" From: Baokun Li When ext4 allocates blocks, we used to just go through the block groups one by one to find a good one. But when there are tons of block groups (like hundreds of thousands or even millions) and not many have free space (meaning they're mostly full), it takes a really long time to check them all, and performance gets bad. So, we added the "mb_optimize_scan" mount option (which is on by default now). It keeps track of some group lists, so when we need a free block, we can just grab a likely group from the right list. This saves time and makes block allocation much faster. But when multiple processes or containers are doing similar things, like constantly allocating 8k blocks, they all try to use the same block group in the same list. Even just two processes doing this can cut the IOPS in half. For example, one container might do 300,000 IOPS, but if you run two at the same time, the total is only 150,000. Since we can already look at block groups in a non-linear way, the first and last groups in the same list are basically the same for finding a block right now. Therefore, add an ext4_try_lock_group() helper function to skip the current group when it is locked by another process, thereby avoiding contention with other processes. This helps ext4 make better use of having multiple block groups. Also, to make sure we don't skip all the groups that have free space when allocating blocks, we won't try to skip busy groups anymore when ac_criteria is CR_ANY_FREE. Performance test data follows: CPU: HUAWEI Kunpeng 920 Memory: 480GB Disk: 480GB SSD SATA 3.2 Test: Running will-it-scale/fallocate2 on 64 CPU-bound containers. Observation: Average fallocate operations per container per second. base patched mb_optimize_scan=3D0 3588 6755 (+88.2%) mb_optimize_scan=3D1 3588 4302 (+19.8%) Signed-off-by: Baokun Li --- fs/ext4/ext4.h | 23 ++++++++++++++--------- fs/ext4/mballoc.c | 14 +++++++++++--- 2 files changed, 25 insertions(+), 12 deletions(-) diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h index 5a20e9cd7184..9c665a620a46 100644 --- a/fs/ext4/ext4.h +++ b/fs/ext4/ext4.h @@ -3494,23 +3494,28 @@ static inline int ext4_fs_is_busy(struct ext4_sb_in= fo *sbi) return (atomic_read(&sbi->s_lock_busy) > EXT4_CONTENTION_THRESHOLD); } =20 +static inline bool ext4_try_lock_group(struct super_block *sb, ext4_group_= t group) +{ + if (!spin_trylock(ext4_group_lock_ptr(sb, group))) + return false; + /* + * We're able to grab the lock right away, so drop the lock + * contention counter. + */ + atomic_add_unless(&EXT4_SB(sb)->s_lock_busy, -1, 0); + return true; +} + static inline void ext4_lock_group(struct super_block *sb, ext4_group_t gr= oup) { - spinlock_t *lock =3D ext4_group_lock_ptr(sb, group); - if (spin_trylock(lock)) - /* - * We're able to grab the lock right away, so drop the - * lock contention counter. - */ - atomic_add_unless(&EXT4_SB(sb)->s_lock_busy, -1, 0); - else { + if (!ext4_try_lock_group(sb, group)) { /* * The lock is busy, so bump the contention counter, * and then wait on the spin lock. */ atomic_add_unless(&EXT4_SB(sb)->s_lock_busy, 1, EXT4_MAX_CONTENTION); - spin_lock(lock); + spin_lock(ext4_group_lock_ptr(sb, group)); } } =20 diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c index 1e98c5be4e0a..5c13d9f8a1cc 100644 --- a/fs/ext4/mballoc.c +++ b/fs/ext4/mballoc.c @@ -896,7 +896,8 @@ static void ext4_mb_choose_next_group_p2_aligned(struct= ext4_allocation_context bb_largest_free_order_node) { if (sbi->s_mb_stats) atomic64_inc(&sbi->s_bal_cX_groups_considered[CR_POWER2_ALIGNED]); - if (likely(ext4_mb_good_group(ac, iter->bb_group, CR_POWER2_ALIGNED))) { + if (likely(ext4_mb_good_group(ac, iter->bb_group, CR_POWER2_ALIGNED)) && + !spin_is_locked(ext4_group_lock_ptr(ac->ac_sb, iter->bb_group))) { *group =3D iter->bb_group; ac->ac_flags |=3D EXT4_MB_CR_POWER2_ALIGNED_OPTIMIZED; read_unlock(&sbi->s_mb_largest_free_orders_locks[i]); @@ -932,7 +933,8 @@ ext4_mb_find_good_group_avg_frag_lists(struct ext4_allo= cation_context *ac, int o list_for_each_entry(iter, frag_list, bb_avg_fragment_size_node) { if (sbi->s_mb_stats) atomic64_inc(&sbi->s_bal_cX_groups_considered[cr]); - if (likely(ext4_mb_good_group(ac, iter->bb_group, cr))) { + if (likely(ext4_mb_good_group(ac, iter->bb_group, cr)) && + !spin_is_locked(ext4_group_lock_ptr(ac->ac_sb, iter->bb_group))) { grp =3D iter; break; } @@ -2911,7 +2913,13 @@ ext4_mb_regular_allocator(struct ext4_allocation_con= text *ac) if (err) goto out; =20 - ext4_lock_group(sb, group); + /* skip busy group */ + if (cr >=3D CR_ANY_FREE) { + ext4_lock_group(sb, group); + } else if (!ext4_try_lock_group(sb, group)) { + ext4_mb_unload_buddy(&e4b); + continue; + } =20 /* * We need to check again after locking the --=20 2.46.1 From nobody Sun Dec 14 12:13:21 2025 Received: from dggsgout12.his.huawei.com (dggsgout12.his.huawei.com [45.249.212.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B127A2222B8; Fri, 23 May 2025 09:03:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.56 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747990997; cv=none; b=Rio+VHv6azMWTcDosFEcnLf3fqTANbx+T6ik6nFwVkL9/Dg7BE5X0qh+FuiBU9ztS7coefwYk0n03dHScyb+j3pa5/7Y8vCIvNUUGCMBvPhXDKLIVPRg9wdmP0Bp3HyQSe9c/c5FlWJsXFPG/P4OSdoae3itcOE79zNGbHuNGRY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747990997; c=relaxed/simple; bh=g/oPaA6mtIU5FilTVbMzKUiYTPHj4nBFEkgpOFOKyLg=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=W+ici4JV1Gfm1yAaKQ5XFteppueiIn6u2Mo998eBhwQwqaktBsbiLtiLAFyDunIbsuAjfhVbMoIjNoPOKpOruch8ZMkGZgNJhJU9VWobzFZIkgyzAsfoWc5xlg4dSQRG496jVQxLz5TCazwRtI89zyiOpKRV1IAxHxn3unEKC0A= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.235]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTP id 4b3fLt4JRFz4f3jYG; Fri, 23 May 2025 17:02:46 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id B0E2E1A0A43; Fri, 23 May 2025 17:03:11 +0800 (CST) Received: from huaweicloud.com (unknown [10.175.104.67]) by APP4 (Coremail) with SMTP id gCh0CgCH61_MOTBocBILNQ--.27999S6; Fri, 23 May 2025 17:03:11 +0800 (CST) From: libaokun@huaweicloud.com To: linux-ext4@vger.kernel.org Cc: tytso@mit.edu, adilger.kernel@dilger.ca, jack@suse.cz, linux-kernel@vger.kernel.org, yi.zhang@huawei.com, yangerkun@huawei.com, libaokun1@huawei.com, libaokun@huaweicloud.com Subject: [PATCH 2/4] ext4: move mb_last_[group|start] to ext4_inode_info Date: Fri, 23 May 2025 16:58:19 +0800 Message-Id: <20250523085821.1329392-3-libaokun@huaweicloud.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20250523085821.1329392-1-libaokun@huaweicloud.com> References: <20250523085821.1329392-1-libaokun@huaweicloud.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: gCh0CgCH61_MOTBocBILNQ--.27999S6 X-Coremail-Antispam: 1UD129KBjvJXoW3XFy5ur45uF1xJw43JFykGrg_yoW7Ary7pr s7G3WrJF4rXw18uw4kW3yDWr1rKa1xGFWUJr1Sgw1jvry3XFySg3ZrtF18ZF97ArZ3ZF1Y vryjya1UCr47Ca7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUPv14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_Jryl82xGYIkIc2 x26xkF7I0E14v26r4j6ryUM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2z4x0 Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJw A2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq3wAS 0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2 IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0 Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwAKzVCY07xG64k0F24lc7CjxV Aaw2AFwI0_Jw0_GFyl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2Iq xVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r 1q6r43MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY 6xkF7I0E14v26r4j6F4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67 AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyTuY vjfU1lkVUUUUU X-CM-SenderInfo: 5olet0hnxqqx5xdzvxpfor3voofrz/1tbiAQARBWgwLIEFawAAsO Content-Type: text/plain; charset="utf-8" From: Baokun Li After we optimized the block group lock, we found another lock contention issue when running will-it-scale/fallocate2 with multiple processes. The fallocate's block allocation and the truncate's block release were fighting over the s_md_lock. The problem is, this lock protects totally different things in those two processes: the list of freed data blocks (s_freed_data_list) when releasing, and where to start looking for new blocks (mb_last_[group|start]) when allocating. Moreover, when allocating data blocks, if the first try (goal allocation) fails and stream allocation is on, it tries a global goal starting from the last group we used (s_mb_last_group). This can make things faster by writing blocks close together on the disk. But when many processes are allocating, they all fight over s_md_lock and might even try to use the same group. This makes it harder to merge extents and can make files more fragmented. If different processes allocate chunks of very different sizes, the free space on the disk can also get fragmented. A small allocation might fit in a partially full group, but a big allocation might have skipped it, leading to the small IO ending up in a more empty group. So, we're changing stream allocation to work per inode. First, it tries the goal, then the last group where that inode successfully allocated a block. This keeps an inode's data closer together. Plus, after moving mb_last_[group|start] to ext4_inode_info, we don't need s_md_lock during block allocation anymore because we already have the write lock on i_data_sem. This gets rid of the contention between allocating and releasing blocks, which gives a huge performance boost to fallocate2. Performance test data follows: CPU: HUAWEI Kunpeng 920 Memory: 480GB Disk: 480GB SSD SATA 3.2 Test: Running will-it-scale/fallocate2 on 64 CPU-bound containers. Observation: Average fallocate operations per container per second. base patched mb_optimize_scan=3D0 6755 23280 (+244.6%) mb_optimize_scan=3D1 4302 10430 (+142.4%) Signed-off-by: Baokun Li --- fs/ext4/ext4.h | 7 ++++--- fs/ext4/mballoc.c | 20 +++++++++----------- fs/ext4/super.c | 2 ++ 3 files changed, 15 insertions(+), 14 deletions(-) diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h index 9c665a620a46..16c14dd09df6 100644 --- a/fs/ext4/ext4.h +++ b/fs/ext4/ext4.h @@ -1171,6 +1171,10 @@ struct ext4_inode_info { __u32 i_csum_seed; =20 kprojid_t i_projid; + + /* where last allocation was done - for stream allocation */ + ext4_group_t i_mb_last_group; + ext4_grpblk_t i_mb_last_start; }; =20 /* @@ -1603,9 +1607,6 @@ struct ext4_sb_info { unsigned int s_mb_order2_reqs; unsigned int s_mb_group_prealloc; unsigned int s_max_dir_size_kb; - /* where last allocation was done - for stream allocation */ - unsigned long s_mb_last_group; - unsigned long s_mb_last_start; unsigned int s_mb_prefetch; unsigned int s_mb_prefetch_limit; unsigned int s_mb_best_avail_max_trim_order; diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c index 5c13d9f8a1cc..ee9696f9bac8 100644 --- a/fs/ext4/mballoc.c +++ b/fs/ext4/mballoc.c @@ -2138,7 +2138,6 @@ static int mb_mark_used(struct ext4_buddy *e4b, struc= t ext4_free_extent *ex) static void ext4_mb_use_best_found(struct ext4_allocation_context *ac, struct ext4_buddy *e4b) { - struct ext4_sb_info *sbi =3D EXT4_SB(ac->ac_sb); int ret; =20 BUG_ON(ac->ac_b_ex.fe_group !=3D e4b->bd_group); @@ -2169,10 +2168,8 @@ static void ext4_mb_use_best_found(struct ext4_alloc= ation_context *ac, folio_get(ac->ac_buddy_folio); /* store last allocated for subsequent stream allocation */ if (ac->ac_flags & EXT4_MB_STREAM_ALLOC) { - spin_lock(&sbi->s_md_lock); - sbi->s_mb_last_group =3D ac->ac_f_ex.fe_group; - sbi->s_mb_last_start =3D ac->ac_f_ex.fe_start; - spin_unlock(&sbi->s_md_lock); + EXT4_I(ac->ac_inode)->i_mb_last_group =3D ac->ac_f_ex.fe_group; + EXT4_I(ac->ac_inode)->i_mb_last_start =3D ac->ac_f_ex.fe_start; } /* * As we've just preallocated more space than @@ -2844,13 +2841,14 @@ ext4_mb_regular_allocator(struct ext4_allocation_co= ntext *ac) MB_NUM_ORDERS(sb)); } =20 - /* if stream allocation is enabled, use global goal */ + /* if stream allocation is enabled, use last goal */ if (ac->ac_flags & EXT4_MB_STREAM_ALLOC) { - /* TBD: may be hot point */ - spin_lock(&sbi->s_md_lock); - ac->ac_g_ex.fe_group =3D sbi->s_mb_last_group; - ac->ac_g_ex.fe_start =3D sbi->s_mb_last_start; - spin_unlock(&sbi->s_md_lock); + struct ext4_inode_info *ei =3D EXT4_I(ac->ac_inode); + + if (ei->i_mb_last_group || ei->i_mb_last_start) { + ac->ac_g_ex.fe_group =3D ei->i_mb_last_group; + ac->ac_g_ex.fe_start =3D ei->i_mb_last_start; + } } =20 /* diff --git a/fs/ext4/super.c b/fs/ext4/super.c index 181934499624..6c49c43bb2cb 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -1416,6 +1416,8 @@ static struct inode *ext4_alloc_inode(struct super_bl= ock *sb) INIT_WORK(&ei->i_rsv_conversion_work, ext4_end_io_rsv_work); ext4_fc_init_inode(&ei->vfs_inode); mutex_init(&ei->i_fc_lock); + ei->i_mb_last_group =3D 0; + ei->i_mb_last_start =3D 0; return &ei->vfs_inode; } =20 --=20 2.46.1 From nobody Sun Dec 14 12:13:21 2025 Received: from dggsgout12.his.huawei.com (dggsgout12.his.huawei.com [45.249.212.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3F94E223DEF; Fri, 23 May 2025 09:03:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.56 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747990997; cv=none; b=ubynRO7wl+F0Gq70D9DLiF/LGiWxJjMVqTp/PsKZ8gId3PTja1LQxrzVrAmm8YJBxFqaOHBuwHWznBbemcuFNyGZvrmesuOTZ0wdYwh5oxky9TH4gKG7BJbBw4gfd5X7L1lZ3SgazZzLBKaKBb3fh0CbZHSx8O0bJFG5aBv+Y6k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747990997; c=relaxed/simple; bh=Hz+Kab1dpqfojfrajVO6nWb6x5jC0sCgaFKb3n05n/A=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=s3KASlT4idGAAim34nO47iFDSUBOKeC46hdczHVxaSyc9lVga7nqTCfIBDEV0D56tAZ37bdqo2ldbbn+TLUHNHpZ8RQ6ZuY8MhKj0vTcj6i1SSg4D3M04wxxBQ+WRdj1+lnSj5bavg62BDTKK/u0IKeC+XCaraE2bHyobvsN27A= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.235]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTP id 4b3fLv07pFz4f3jdk; Fri, 23 May 2025 17:02:47 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id 21C861A06DD; Fri, 23 May 2025 17:03:12 +0800 (CST) Received: from huaweicloud.com (unknown [10.175.104.67]) by APP4 (Coremail) with SMTP id gCh0CgCH61_MOTBocBILNQ--.27999S7; Fri, 23 May 2025 17:03:11 +0800 (CST) From: libaokun@huaweicloud.com To: linux-ext4@vger.kernel.org Cc: tytso@mit.edu, adilger.kernel@dilger.ca, jack@suse.cz, linux-kernel@vger.kernel.org, yi.zhang@huawei.com, yangerkun@huawei.com, libaokun1@huawei.com, libaokun@huaweicloud.com Subject: [PATCH 3/4] ext4: get rid of some obsolete EXT4_MB_HINT flags Date: Fri, 23 May 2025 16:58:20 +0800 Message-Id: <20250523085821.1329392-4-libaokun@huaweicloud.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20250523085821.1329392-1-libaokun@huaweicloud.com> References: <20250523085821.1329392-1-libaokun@huaweicloud.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: gCh0CgCH61_MOTBocBILNQ--.27999S7 X-Coremail-Antispam: 1UD129KBjvJXoW7AF4ruryDCryfZrykJr17trb_yoW8WryxpF srJF95KryIqw18uws7XwnxKw47G3yIk34DZrn0qw1F9as8Jrn5JFn2gr10v3WFv3ykAr98 XFyq939rGr1Uu3JanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUPv14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_JrWl82xGYIkIc2 x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2z4x0 Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr1j6F4UJw A2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq3wAS 0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2 IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0 Y48IcxkI7VAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwAKzVCY07xG64k0F24lc7CjxV Aaw2AFwI0_Jw0_GFyl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2Iq xVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r 1q6r43MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY 6xkF7I0E14v26r4j6F4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67 AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyTuY vjfUOnmRUUUUU X-CM-SenderInfo: 5olet0hnxqqx5xdzvxpfor3voofrz/1tbiAQARBWgwLIEFbAABsI Content-Type: text/plain; charset="utf-8" From: Baokun Li Since nobody has used these EXT4_MB_HINT flags for ages, let's remove them. Signed-off-by: Baokun Li Reviewed-by: Jan Kara Reviewed-by: Ojaswin Mujoo --- fs/ext4/ext4.h | 6 ------ include/trace/events/ext4.h | 3 --- 2 files changed, 9 deletions(-) diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h index 16c14dd09df6..f6d01702423d 100644 --- a/fs/ext4/ext4.h +++ b/fs/ext4/ext4.h @@ -185,14 +185,8 @@ enum criteria { =20 /* prefer goal again. length */ #define EXT4_MB_HINT_MERGE 0x0001 -/* blocks already reserved */ -#define EXT4_MB_HINT_RESERVED 0x0002 -/* metadata is being allocated */ -#define EXT4_MB_HINT_METADATA 0x0004 /* first blocks in the file */ #define EXT4_MB_HINT_FIRST 0x0008 -/* search for the best chunk */ -#define EXT4_MB_HINT_BEST 0x0010 /* data is being allocated */ #define EXT4_MB_HINT_DATA 0x0020 /* don't preallocate (for tails) */ diff --git a/include/trace/events/ext4.h b/include/trace/events/ext4.h index 156908641e68..33b204165cc0 100644 --- a/include/trace/events/ext4.h +++ b/include/trace/events/ext4.h @@ -23,10 +23,7 @@ struct partial_cluster; =20 #define show_mballoc_flags(flags) __print_flags(flags, "|", \ { EXT4_MB_HINT_MERGE, "HINT_MERGE" }, \ - { EXT4_MB_HINT_RESERVED, "HINT_RESV" }, \ - { EXT4_MB_HINT_METADATA, "HINT_MDATA" }, \ { EXT4_MB_HINT_FIRST, "HINT_FIRST" }, \ - { EXT4_MB_HINT_BEST, "HINT_BEST" }, \ { EXT4_MB_HINT_DATA, "HINT_DATA" }, \ { EXT4_MB_HINT_NOPREALLOC, "HINT_NOPREALLOC" }, \ { EXT4_MB_HINT_GROUP_ALLOC, "HINT_GRP_ALLOC" }, \ --=20 2.46.1 From nobody Sun Dec 14 12:13:21 2025 Received: from dggsgout11.his.huawei.com (dggsgout11.his.huawei.com [45.249.212.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 94A3E224893; Fri, 23 May 2025 09:03:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.51 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747990997; cv=none; b=aKqhLpoY0lD9m1VYLVOxw5SA1xZz8ybJhJnw2NNowN5DzsAVQ0Bg8/PzNB/44ixuFU8FcKZ4LahVRfc5eUb0+XrUYXiHQWAmhiTl5G/iTWS+7IJjl6tuQry6DpH1B3jcjhHbmxJ9j7NZNno8nWjf2pJk7a8MBzb9l+Z4HM1uw5A= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747990997; c=relaxed/simple; bh=7l5SfPkeJLkABkv2Lg6ATbrd6Cq4z5wQ6b7/+3v9SWQ=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=Wxj3y0UxeFAveV07n5Qlj3soo6SXXjCGwrQ4kQqtOfYubL1ydkRboLgUcicr0rIxp3fTy+7aLyfLFC/okVK5QtNz/eyKugcbAta7jUVrlPXORTduWSExpJSop62jUgjg+aG0Mgdzov1GRiUuOQkgRkXdehR5Y8IQeodeIoO+0Mk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.216]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTPS id 4b3fMP2ggPzYQv7c; Fri, 23 May 2025 17:03:13 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.128]) by mail.maildlp.com (Postfix) with ESMTP id 885961A1C4D; Fri, 23 May 2025 17:03:12 +0800 (CST) Received: from huaweicloud.com (unknown [10.175.104.67]) by APP4 (Coremail) with SMTP id gCh0CgCH61_MOTBocBILNQ--.27999S8; Fri, 23 May 2025 17:03:12 +0800 (CST) From: libaokun@huaweicloud.com To: linux-ext4@vger.kernel.org Cc: tytso@mit.edu, adilger.kernel@dilger.ca, jack@suse.cz, linux-kernel@vger.kernel.org, yi.zhang@huawei.com, yangerkun@huawei.com, libaokun1@huawei.com, libaokun@huaweicloud.com Subject: [PATCH 4/4] ext4: fix typo in CR_GOAL_LEN_SLOW comment Date: Fri, 23 May 2025 16:58:21 +0800 Message-Id: <20250523085821.1329392-5-libaokun@huaweicloud.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20250523085821.1329392-1-libaokun@huaweicloud.com> References: <20250523085821.1329392-1-libaokun@huaweicloud.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-CM-TRANSID: gCh0CgCH61_MOTBocBILNQ--.27999S8 X-Coremail-Antispam: 1UD129KBjvdXoWruF4DuF1kCFWfur45KF1fXrb_yoWxArX_ta yUZr48Wrnxtrn29a4rur9aqFnFgr48Gr1UuFZ8GrnYqayUX3yfX3Wvyrs8Z3Z8ur4UAFn8 ZwsIqF17AF92qjkaLaAFLSUrUUUUjb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUby8FF20E14v26rWj6s0DM7CY07I20VC2zVCF04k26cxKx2IYs7xG 6rWj6s0DM7CIcVAFz4kK6r1j6r18M28IrcIa0xkI8VA2jI8067AKxVWUAVCq3wA2048vs2 IY020Ec7CjxVAFwI0_Xr0E3s1l8cAvFVAK0II2c7xJM28CjxkF64kEwVA0rcxSw2x7M28E F7xvwVC0I7IYx2IY67AKxVW7JVWDJwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVW8Jr0_Cr 1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s0D M2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjx v20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1l F7xvr2IYc2Ij64vIr41lF7I21c0EjII2zVCS5cI20VAGYxC7M4kE6xkIj40Ew7xC0wCY1x 0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC2 0s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI 0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv2 0xvEc7CjxVAFwI0_Gr0_Cr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0xvEx4A2js IE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZF pf9x0JU9Aw3UUUUU= X-CM-SenderInfo: 5olet0hnxqqx5xdzvxpfor3voofrz/1tbiAQARBWgwLIEFbAADsK Content-Type: text/plain; charset="utf-8" From: Baokun Li Remove the superfluous "find_". Signed-off-by: Baokun Li Reviewed-by: Jan Kara Reviewed-by: Ojaswin Mujoo --- fs/ext4/ext4.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h index f6d01702423d..1182700901cc 100644 --- a/fs/ext4/ext4.h +++ b/fs/ext4/ext4.h @@ -157,7 +157,7 @@ enum criteria { =20 /* * Reads each block group sequentially, performing disk IO if - * necessary, to find find_suitable block group. Tries to + * necessary, to find suitable block group. Tries to * allocate goal length but might trim the request if nothing * is found after enough tries. */ --=20 2.46.1