[PATCH v2 4.19 0/4] ext4: improve delalloc buffer write performance

[PATCH v2 4.19 0/4] ext4: improve delalloc buffer write performance

[WangYuli]

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(-)

-- 
2.31.1

Re: [PATCH v2 4.19 0/4] ext4: improve delalloc buffer write performance

[Greg KH]

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

Re: [PATCH v2 4.19 0/4] ext4: improve delalloc buffer write performance

[Greg KH]

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

Re: [PATCH v2 4.19 0/4] ext4: improve delalloc buffer write performance

[WangYuli]

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

Re: [PATCH v2 4.19 0/4] ext4: improve delalloc buffer write performance

[Greg KH]

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