| 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: <6fe9c4be-a2d6-4000-85e1-cdf3c0dab196@huawei.com> Date: Sat, 22 Nov 2025 08:13:39 +0800 From: Baokun Li <libaokun1@...wei.com> To: Ojaswin Mujoo <ojaswin@...ux.ibm.com> CC: <linux-ext4@...r.kernel.org>, <tytso@....edu>, <adilger.kernel@...ger.ca>, <jack@...e.cz>, <linux-kernel@...r.kernel.org>, <libaokun@...weicloud.com>, <kernel@...kajraghav.com>, <mcgrof@...nel.org>, <ebiggers@...nel.org>, <willy@...radead.org>, <yi.zhang@...wei.com>, <yangerkun@...wei.com>, <chengzhihao1@...wei.com>, Baokun Li <libaokun1@...wei.com> Subject: Re: [PATCH v4 00/24] ext4: enable block size larger than page size On 2025-11-21 18:26, Ojaswin Mujoo wrote: > On Fri, Nov 21, 2025 at 05:06:30PM +0800, libaokun@...weicloud.com wrote: >> From: Baokun Li <libaokun1@...wei.com> >> >> Changes since v3: >> * Collect RVB from Jan Kara, Zhang Yi and Pankaj Raghav. >> (Thank you for your review!) >> * Patch 21: Fix lock imbalance in ext4_change_inode_journal_flag. >> (Suggested by Dan Carpenter) >> >> [v3]: https://lore.kernel.org/r/20251111142634.3301616-1-libaokun@huaweicloud.com >> >> Changes since v2: >> * Collect RVB from Jan Kara, Zhang Yi and Pankaj Raghav. >> (Thank you for your review!) >> * Patch 21: Before switching the inode journalling mode, drop all >> page cache of that inode and invoke filemap_write_and_wait() >> unconditionally. (Suggested by Jan Kara) >> * Patch 22: Extend fs-verity to support large folios in addition to >> large block size. (Suggested by Jan Kara) >> * Patch 24: Add a blocksize_gt_pagesize sysfs interface to help users >> (e.g., mke2fs) determine whether the current kernel supports bs > ps. >> In addition, remove the experimental tag. (Suggested by Theodore Ts'o) >> >> [v2]: https://lore.kernel.org/r/20251107144249.435029-1-libaokun@huaweicloud.com >> >> Changes since v1: >> * Collect RVB from Jan Kara and Zhang Yi. (Thanks for your review!) >> * Patch 4: Just use blocksize in the rounding.(Suggested by Jan Kara) >> * Patch 7: use kvmalloc() instead of allocating contiguous physical >> pages.(Suggested by Jan Kara) >> * Patch 12: Fix some typos.(Suggested by Jan Kara) >> * Use clearer naming: EXT4_LBLK_TO_PG() and EXT4_PG_TO_LBLK(). >> (Suggested by Jan Kara) >> * Patch 21: removed. After rebasing on Ted’s latest dev branch, this >> patch is no longer needed. >> * Patch 22-23: removed. The issue was resolved by removing the WARN_ON >> in the MM code, so we now rely on patch [1].(Suggested by Matthew) >> * Add new Patch 21 to support data=journal under LBS. (Suggested by >> Jan Kara) >> * Add new Patch 22 to support fs verity under LBS. >> * New Patch 23: add the s_max_folio_order field instead of introducing >> the EXT4_MF_LARGE_FOLIO flag. >> * New Patch 24: rebase adaptation. >> >> [v1]: https://lore.kernel.org/r/20251025032221.2905818-1-libaokun@huaweicloud.com >> >> ====== >> >> This series enables block size > page size (Large Block Size) in EXT4. >> >> Since large folios are already supported for regular files, the required >> changes are not substantial, but they are scattered across the code. >> The changes primarily focus on cleaning up potential division-by-zero >> errors, resolving negative left/right shifts, and correctly handling >> mutually exclusive mount options. >> >> One somewhat troublesome issue is that allocating page units greater than >> order-1 with __GFP_NOFAIL in __alloc_pages_slowpath() can trigger an >> unexpected WARN_ON. With LBS support, EXT4 and jbd2 may use __GFP_NOFAIL >> to allocate large folios when reading metadata. The issue was resolved by >> removing the WARN_ON in the MM code, so we now rely on patch [1]. >> >> [1]: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=ee040cbd6e48 >> >> Patch series based on Ted’s latest dev branch. >> >> `kvm-xfstests -c ext4/all -g auto` has been executed with no new failures. >> `kvm-xfstests -c ext4/32k -g auto` has been executed with no new failures. >> `kvm-xfstests -c ext4/64k -g auto` has been executed with no new failures, >> but allocation failures for large folios may trigger warn_alloc() warnings, >> tests with 32k or smaller block sizes have not exhibited any page allocation >> failures. >> >> Here are some performance test data for your reference: >> >> Testing EXT4 filesystems with different block sizes, measuring >> single-threaded dd bandwidth for BIO/DIO with varying bs values. >> >> Before(PAGE_SIZE=4096): >> >> BIO | bs=4k | bs=8k | bs=16k | bs=32k | bs=64k >> --------------|----------|----------|----------|----------|------------ >> 4k | 1.5 GB/s | 2.1 GB/s | 2.8 GB/s | 3.4 GB/s | 3.8 GB/s >> 8k (bigalloc)| 1.4 GB/s | 2.0 GB/s | 2.6 GB/s | 3.1 GB/s | 3.4 GB/s >> 16k(bigalloc)| 1.5 GB/s | 2.0 GB/s | 2.6 GB/s | 3.2 GB/s | 3.6 GB/s >> 32k(bigalloc)| 1.5 GB/s | 2.1 GB/s | 2.7 GB/s | 3.3 GB/s | 3.7 GB/s >> 64k(bigalloc)| 1.5 GB/s | 2.1 GB/s | 2.8 GB/s | 3.4 GB/s | 3.8 GB/s >> >> DIO | bs=4k | bs=8k | bs=16k | bs=32k | bs=64k >> --------------|----------|----------|----------|----------|------------ >> 4k | 194 MB/s | 366 MB/s | 626 MB/s | 1.0 GB/s | 1.4 GB/s >> 8k (bigalloc)| 188 MB/s | 359 MB/s | 612 MB/s | 996 MB/s | 1.4 GB/s >> 16k(bigalloc)| 208 MB/s | 378 MB/s | 642 MB/s | 1.0 GB/s | 1.4 GB/s >> 32k(bigalloc)| 184 MB/s | 368 MB/s | 637 MB/s | 995 MB/s | 1.4 GB/s >> 64k(bigalloc)| 208 MB/s | 389 MB/s | 634 MB/s | 1.0 GB/s | 1.4 GB/s >> >> Patched(PAGE_SIZE=4096): >> >> BIO | bs=4k | bs=8k | bs=16k | bs=32k | bs=64k >> ---------|----------|----------|----------|----------|------------ >> 4k | 1.5 GB/s | 2.1 GB/s | 2.8 GB/s | 3.4 GB/s | 3.8 GB/s >> 8k (LBS)| 1.7 GB/s | 2.3 GB/s | 3.2 GB/s | 4.2 GB/s | 4.7 GB/s >> 16k(LBS)| 2.0 GB/s | 2.7 GB/s | 3.6 GB/s | 4.7 GB/s | 5.4 GB/s >> 32k(LBS)| 2.2 GB/s | 3.1 GB/s | 3.9 GB/s | 4.9 GB/s | 5.7 GB/s >> 64k(LBS)| 2.4 GB/s | 3.3 GB/s | 4.2 GB/s | 5.1 GB/s | 6.0 GB/s >> >> DIO | bs=4k | bs=8k | bs=16k | bs=32k | bs=64k >> ---------|----------|----------|----------|----------|------------ >> 4k | 204 MB/s | 355 MB/s | 627 MB/s | 1.0 GB/s | 1.4 GB/s >> 8k (LBS)| 210 MB/s | 356 MB/s | 602 MB/s | 997 MB/s | 1.4 GB/s >> 16k(LBS)| 191 MB/s | 361 MB/s | 589 MB/s | 981 MB/s | 1.4 GB/s >> 32k(LBS)| 181 MB/s | 330 MB/s | 581 MB/s | 951 MB/s | 1.3 GB/s >> 64k(LBS)| 148 MB/s | 272 MB/s | 499 MB/s | 840 MB/s | 1.3 GB/s >> >> >> The results show: >> >> * The code changes have almost no impact on the original 4k write >> performance of ext4. >> * Compared with bigalloc, LBS improves BIO write performance by about 50% >> on average. >> * Compared with bigalloc, LBS shows degradation in DIO write performance, >> which increases as the filesystem block size grows and the test bs >> decreases, with a maximum degradation of about 30%. >> >> The DIO regression is primarily due to the increased time spent in >> crc32c_arch() within ext4_block_bitmap_csum_set() during block allocation, >> as the block size grows larger. This indicates that larger filesystem block >> sizes are not always better; please choose an appropriate block size based >> on your I/O workload characteristics. >> >> We are also planning further optimizations for block allocation under LBS >> in the future. >> >> Comments and questions are, as always, welcome. >> >> Thanks, >> Baokun > Hi Baokun, > > I've gone throught the series and the changes look mostly straight > forward to me. I've started running some regression tests on my PowerPC > machine. It's 64k pgsz so I can only test upto bs == ps, but everything > looks normal for now. I'll report here if there are any regressions. > > Regardless, feel free to add: > Reviewed-by: Ojaswin Mujoo <ojaswin@...ux.ibm.com> Thank you for your review and testing! Cheers, Baokun
Powered by blists - more mailing lists