Changes since v1: Fixed some formatting errors to make the patchset less confusing.
A patchset from linux-5.15 should be backported to 4.19 that can significantly improve ext4 fs read and write performance. Unixbench test results for linux-4.19.318 on Phytium D2000 CPU are shown below.
Test cmd: (Phytium D2000 only has 8 cores) ./Run fs -c 8
Before this patch set: File Copy 1024 bufsize 2000 maxblocks 1124181 File Copy 256 bufsize 500 maxblocks 281885 File Copy 4096 bufsize 8000 maxblocks 3383785 File Read 1024 bufsize 2000 maxblocks 8702173 File Read 256 bufsize 500 maxblocks 3869384 File Read 4096 bufsize 8000 maxblocks 13043151 File Write 1024 bufsize 2000 maxblocks 1107185 File Write 256 bufsize 500 maxblocks 270493 File Write 4096 bufsize 8000 maxblocks 4018084
After this patch set: File Copy 1024 bufsize 2000 maxblocks 2026206 File Copy 256 bufsize 500 maxblocks 829534 File Copy 4096 bufsize 8000 maxblocks 4066659 File Read 1024 bufsize 2000 maxblocks 8877219 File Read 256 bufsize 500 maxblocks 3997445 File Read 4096 bufsize 8000 maxblocks 13179885 File Write 1024 bufsize 2000 maxblocks 4256929 File Write 256 bufsize 500 maxblocks 1305320 File Write 4096 bufsize 8000 maxblocks 10721052
We can observe a quantum leap in the test results as a consequence of applying this patchset
Link: https://lore.kernel.org/all/20210716122024.1105856-1-yi.zhang@huawei.com/
Original description:
This patchset address to improve buffer write performance with delalloc. The first patch reduce the unnecessary update i_disksize, the second two patch refactor the inline data write procedure and also do some small fix, the last patch do improve by remove all unnecessary journal handle in the delalloc write procedure.
After this patch set, we could get a lot of performance improvement. Below is the Unixbench comparison data test on my machine with 'Intel Xeon Gold 5120' CPU and nvme SSD backend.
Test cmd:
./Run -c 56 -i 3 fstime fsbuffer fsdisk
Before this patch set:
System Benchmarks Partial Index BASELINE RESULT INDEX File Copy 1024 bufsize 2000 maxblocks 3960.0 422965.0 1068.1 File Copy 256 bufsize 500 maxblocks 1655.0 105077.0 634.9 File Copy 4096 bufsize 8000 maxblocks 5800.0 1429092.0 2464.0 ======== System Benchmarks Index Score (Partial Only) 1186.6
After this patch set:
System Benchmarks Partial Index BASELINE RESULT INDEX File Copy 1024 bufsize 2000 maxblocks 3960.0 732716.0 1850.3 File Copy 256 bufsize 500 maxblocks 1655.0 184940.0 1117.5 File Copy 4096 bufsize 8000 maxblocks 5800.0 2427152.0 4184.7 ======== System Benchmarks Index Score (Partial Only) 2053.0
Zhang Yi (4): ext4: check and update i_disksize properly ext4: correct the error path of ext4_write_inline_data_end() ext4: factor out write end code of inline file ext4: drop unnecessary journal handle in delalloc write
fs/ext4/ext4.h | 3 - fs/ext4/inline.c | 120 ++++++++++++++++++------------------- fs/ext4/inode.c | 150 ++++++++++++----------------------------------- 3 files changed, 99 insertions(+), 174 deletions(-)
On Sun, Jul 21, 2024 at 12:04:06AM +0800, WangYuli wrote:
Changes since v1: Fixed some formatting errors to make the patchset less confusing.
A patchset from linux-5.15 should be backported to 4.19 that can significantly improve ext4 fs read and write performance. Unixbench test results for linux-4.19.318 on Phytium D2000 CPU are shown below.
What about 5.4.y and 5.10.y? You can't just skip those trees :(
thanks,
greg k-h
On Sun, Jul 21, 2024 at 12:04:06AM +0800, WangYuli wrote:
Changes since v1: Fixed some formatting errors to make the patchset less confusing.
A patchset from linux-5.15 should be backported to 4.19 that can significantly improve ext4 fs read and write performance. Unixbench test results for linux-4.19.318 on Phytium D2000 CPU are shown below.
Also, this looks like a performance issue, why not just use a newer kernel (i.e. 5.15.y) to get the benefit of this, and many other, increased performance fixes? 4.19.y is only going to be alive for a few more months, if you haven't already planned to move off of it yet, you need to do so now.
thanks,
greg k-h
Hi greg k-h,
As a commercial Linux distribution maintainer, we understand that
even though upstream support for linux-4.19.y is ending, our users'
reliance on this kernel version will not cease immediately.
They often lack the time or resources to promptly migrate all their
devices to a newer kernel, due to considerations such as stability,
operational costs, and other factors.
Therefore, to provide a more graceful conclusion to the linux-4.19.y
lifecycle, we propose backporting these performance optimizations
to extend its useful life and ensure a smooth transition for commercial
users by the way.
Of course, we appreciate your suggestion and will prioritize backporting
these optimizations to linux-5.10.y and linux 5.4.y first.
Stay tuned for updates. We are committed to staying informed about kernel
updates and community trends. Thanks.
Sincerely,
--
WangYuli
On Wed, Jul 24, 2024 at 12:55:52PM +0800, WangYuli wrote:
Hi greg k-h,
As a commercial Linux distribution maintainer, we understand that even though upstream support for linux-4.19.y is ending, our users' reliance on this kernel version will not cease immediately.
Good luck to them, given that almost immediately after it goes out of support it will become insecure :(
They often lack the time or resources to promptly migrate all their devices to a newer kernel, due to considerations such as stability, operational costs, and other factors.
They have had 6 years to plan for this, how much time do they need?
Therefore, to provide a more graceful conclusion to the linux-4.19.y lifecycle, we propose backporting these performance optimizations to extend its useful life and ensure a smooth transition for commercial users by the way.
Performance optimizations for old kernels like this are not a good idea, please just have them move to a more modern, and actually supported, kernel instead if they wish to have performance improvements. Otherwise you are ensuring they will never move.
good luck!
greg k-h
linux-stable-mirror@lists.linaro.org
-
Greg KH -
WangYuli