| 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: <CACX6voDfcTQzQJj=5Q-SLi0in1hXpo=Ri28rX73Og3GTObPBWA@mail.gmail.com>
Date: Mon, 19 Sep 2022 16:18:32 +0100
From: hazem ahmed mohamed <hazem.ahmed.abuelfotoh@...il.com>
To: "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
"tytso@....edu" <tytso@....edu>,
"adilger.kernel@...ger.ca" <adilger.kernel@...ger.ca>,
"regressions@...ts.linux.dev" <regressions@...ts.linux.dev>,
"stable@...r.kernel.org" <stable@...r.kernel.org>
Cc: "Mohamed Abuelfotoh, Hazem" <abuehaze@...zon.com>
Subject: Ext4: Buffered random writes performance regression with
dioread_nolock enabled
Hey Team,
I am sending this e-mail to report a performance regression that’s
caused by commit 244adf6426(ext4: make dioread_nolock the default) , I
am listing the performance regression symptoms below & our analysis
for the reported regression.
Reproduction Environment:
m5.24xlarge AWS EC2 instance that’s equipped with 96 vCPUs & 384 GiB of memory
Disk: io1 16 TiB AWS EBS volume that should be able to achieve 64 IOPS
with throughput of 1000 MiB/s.
Reproduction steps:
We have seen a sharp regression in the achieved Disk IOPS &
throughput running random buffered writes I/O fio test as shown below.
Format and mount:
$sudo mkdir -p /dbdata
$mke2fs -E lazy_itable_init=0,lazy_journal_init=0 -m 1 -t ext4 -b 4096
/dev/nvme1n1
$mount -t ext4 -o noatime,nodiratime,data=ordered /dev/nvme1n1 /dbdata
Mount options:
/dev/nvme1n1 on /dbdata type ext4 (rw,noatime,nodiratime,data=ordered)
Running the below script:
[root@...xx-xx-xx-xx ec2-user]# cat fio_test.sh
#!/bin/bash
for i in `seq 1 2`; do
rm -rf /rdsdbdata/*
/usr/bin/fio --name=16kb_rand_write_only_2048_jobs
--directory=/dbdata --rw=randwrite --ioengine=sync --fdatasync=1
--buffered=1 --bs=16k --max-jobs=2048 --numjobs=2048 --runtime=30
--thread --filesize=28800000 --fsync=1 --group_reporting
--create_only=1 > /dev/null
sudo echo 1 > /proc/sys/vm/drop_caches
echo "start test ${i}"
/usr/bin/fio --name=16kb_rand_write_only_2048_jobs
--directory=/dbdata --rw=randwrite --ioengine=sync --fdatasync=1
--buffered=1 --bs=16k --max-jobs=2048 --numjobs=2048 --runtime=60
--time_based --thread --filesize=28800000 --fsync=1 --group_reporting
| grep iops
done
Symptoms:
The regression has been seen after upgrading from kernel 4.14 to 5.10
as shown below. it’s still reproducible on the latest upstream kernel
5.19 as the previously mentioned commit has been in the Linux kernel
since 5.6.
Kernel 4.14.287-215.504.amzn2.x86_64
[root@...xx-xx-xx-xx ec2-user]# ./fio_test.sh
start test 1
write: io=56335MB, bw=320416KB/s, iops=20026, runt=180038msec
start test 2
write: io=55111MB, bw=313421KB/s, iops=19588, runt=180056msec
Kernel 5.10.130-118.517.amzn2.x86_64
[root@...xx-xx-xx-xx ec2-user]# ./fio_test.sh
start test 1
write: io=911744KB, bw=5055.5KB/s, iops=315, runt=180350msec
start test 2
write: io=1075.6MB, bw=6089.4KB/s, iops=380, runt=180872msec
Analysis:
Doing a kernel bisect pointed out to the previously mentioned commit
as culprit behind the reported regression. We have tried to remount
the ext4 filesystem disabling dioread_nolock and that was enough to
bring the performance back to what it was before the commit.
We have done some performance debugging using perf event flame graphs
The dioread_nolock captured flame graphs are showing that 93.47% of
the time is been spent on fsync calls with the below path:
Fsync->entry_SYSCALL_64_after_hwframe->do_syscall_64->__x64_sys_fsync->ext4_sync_file->file_write_and_wait_range->__filemap_fdatawrite_range->do_writepages->
ext4_writepages->__ext4_journal_start_sb-> jbd2__journal_start->
start_this_handle->add_transaction_credits-> prepare_to_wait_event->
_raw_spin_lock_irqsave-> native_queued_spin_lock_slowpath.
With dioread_lock 51% of the time is been spent on fsync->
entry_SYSCALL_64_after_hwframe-> do_syscall_64-> __x64_sys_fsync->
ext4_sync_file->jbd2_log_wait_commit->prepare_to_wait_event->_raw_spin_lock_irqsave->native_queued_spin_lock_slowpath.
Doing a quick perf diff comparison between dioread_nolock &
dioread_lock and ironically it looks like we have kind of higher spin
lock contention when using dioread_nolock
# Event 'cycles'
#
# Baseline Delta Abs Shared Object Symbol
# ........ ......... ...................
.................................................
#
96.46% -14.86% [kernel.kallsyms] [k] native_queued_spin_lock_slowpath
1.05% +2.19% fio [.] 0x0000000000019f00
0.00% +1.52% [kernel.kallsyms] [k] start_this_handle
0.04% +1.31% [kernel.kallsyms] [k] osq_lock
0.03% +0.73% [kernel.kallsyms] [k]
mwait_idle_with_hints.constprop.0
0.01% +0.60% [kernel.kallsyms] [k] copy_user_enhanced_fast_string
0.01% +0.58% [kernel.kallsyms] [k] _raw_read_lock
0.03% +0.48% [kernel.kallsyms] [k] add_transaction_credits
0.01% +0.34% [kernel.kallsyms] [k] queued_read_lock_slowpath
The flame graphs were showing that with dioread_lock enabled, most of
the CPU time is been spent in the add_transaction_credits function
which is responsible for making sure there is enough journal space
before adding the handle to the running transaction.
While running the reproduction with dioread_lock enabled and using
/proc/sysrq we were able to see that the fio process is waiting for
journal space most of the time and that’s why the lock contention on
journal->j_state_lock was higher with dioread_lock enabled.
Aug 19 14:52:09 ip-172-31-8-128 kernel: task:fio state:D
stack: 0 pid:34280 ppid: 26341 flags:0x00000080
Aug 19 14:52:09 ip-172-31-8-128 kernel: Call Trace:
Aug 19 14:52:09 ip-172-31-8-128 kernel: __schedule+0x1f9/0x660
Aug 19 14:52:09 ip-172-31-8-128 kernel: schedule+0x46/0xb0
Aug 19 14:52:09 ip-172-31-8-128 kernel: schedule_preempt_disabled+0xa/0x10
Aug 19 14:52:09 ip-172-31-8-128 kernel: __mutex_lock.constprop.0+0x12d/0x460
Aug 19 14:52:09 ip-172-31-8-128 kernel: mutex_lock_io+0x39/0x50
Aug 19 14:52:09 ip-172-31-8-128 kernel:
__jbd2_log_wait_for_space+0xc5/0x1a0 [jbd2]
Aug 19 14:52:09 ip-172-31-8-128 kernel:
add_transaction_credits+0x288/0x2a0 [jbd2]
Aug 19 14:52:09 ip-172-31-8-128 kernel: start_this_handle+0x12d/0x4d0 [jbd2]
Aug 19 14:52:09 ip-172-31-8-128 kernel: ? jbd2__journal_start+0x8d/0x1e0 [jbd2]
Aug 19 14:52:09 ip-172-31-8-128 kernel: ? kmem_cache_alloc+0x132/0x260
Aug 19 14:52:09 ip-172-31-8-128 kernel: jbd2__journal_start+0xf7/0x1e0 [jbd2]
Aug 19 14:52:09 ip-172-31-8-128 kernel:
__ext4_journal_start_sb+0xf3/0x110 [ext4]
Aug 19 14:52:09 ip-172-31-8-128 kernel: ext4_dirty_inode+0x3d/0x80 [ext4]
Aug 19 14:52:09 ip-172-31-8-128 kernel: __mark_inode_dirty+0x192/0x2f0
Aug 19 14:52:09 ip-172-31-8-128 kernel: generic_update_time+0x68/0xc0
Aug 19 14:52:09 ip-172-31-8-128 kernel: file_update_time+0x123/0x140
Aug 19 14:52:09 ip-172-31-8-128 kernel: ? generic_write_checks+0x61/0xc0
Aug 19 14:52:09 ip-172-31-8-128 kernel:
ext4_buffered_write_iter+0x5a/0x160 [ext4]
Aug 19 14:52:09 ip-172-31-8-128 kernel: new_sync_write+0x11c/0x1b0
Aug 19 14:52:09 ip-172-31-8-128 kernel: vfs_write+0x1bd/0x260
Aug 19 14:52:09 ip-172-31-8-128 kernel: ksys_write+0x5f/0xe0
Aug 19 14:52:09 ip-172-31-8-128 kernel: do_syscall_64+0x33/0x40
Aug 19 14:52:09 ip-172-31-8-128 kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9
Aug 19 14:52:09 ip-172-31-8-128 kernel: RIP: 0033:0x7f13bde28559
Aug 19 14:52:09 ip-172-31-8-128 kernel: RSP: 002b:00007f04e0dde8e0
EFLAGS: 00000293 ORIG_RAX: 0000000000000001
Aug 19 14:52:09 ip-172-31-8-128 kernel: RAX: ffffffffffffffda RBX:
00007f0fa8005280 RCX: 00007f13bde28559
Aug 19 14:52:09 ip-172-31-8-128 kernel: RDX: 0000000000004000 RSI:
00007f0fa8005280 RDI: 00000000000006bf
Aug 19 14:52:09 ip-172-31-8-128 kernel: RBP: 0000000000004000 R08:
0000000000000000 R09: 0000000000000001
Aug 19 14:52:09 ip-172-31-8-128 kernel: R10: 0000000000000000 R11:
0000000000000293 R12: 00007f13a9e562c8
Aug 19 14:52:09 ip-172-31-8-128 kernel: R13: 0000000000004000 R14:
00007f13a9e63c40 R15: 00007f13a9e63ae0
We did the same with dioread_lock enabled and I couldn't see any
reference for __jbd2_log_wait_for_space function which is the one
responsible for waiting for enough journal space to be available.
Aug 19 15:22:35 ip-172-31-8-128 kernel: task:fio state:D
stack: 0 pid:77710 ppid: 71030 flags:0x00004080
Aug 19 15:22:35 ip-172-31-8-128 kernel: Call Trace:
Aug 19 15:22:35 ip-172-31-8-128 kernel: __schedule+0x1f9/0x660
Aug 19 15:22:35 ip-172-31-8-128 kernel: schedule+0x46/0xb0
Aug 19 15:22:35 ip-172-31-8-128 kernel: wait_transaction_locked+0x8a/0xd0 [jbd2]
Aug 19 15:22:35 ip-172-31-8-128 kernel: ? add_wait_queue_exclusive+0x70/0x70
Aug 19 15:22:35 ip-172-31-8-128 kernel:
add_transaction_credits+0xd6/0x2a0 [jbd2]
Aug 19 15:22:35 ip-172-31-8-128 kernel: start_this_handle+0x12d/0x4d0 [jbd2]
Aug 19 15:22:35 ip-172-31-8-128 kernel: ? jbd2__journal_start+0x8d/0x1e0 [jbd2]
Aug 19 15:22:35 ip-172-31-8-128 kernel: ? kmem_cache_alloc+0x132/0x260
Aug 19 15:22:35 ip-172-31-8-128 kernel: jbd2__journal_start+0xf7/0x1e0 [jbd2]
Aug 19 15:22:35 ip-172-31-8-128 kernel:
__ext4_journal_start_sb+0xf3/0x110 [ext4]
Aug 19 15:22:35 ip-172-31-8-128 kernel: ext4_dirty_inode+0x3d/0x80 [ext4]
Aug 19 15:22:35 ip-172-31-8-128 kernel: __mark_inode_dirty+0x192/0x2f0
Aug 19 15:22:35 ip-172-31-8-128 kernel: generic_update_time+0x68/0xc0
Aug 19 15:22:35 ip-172-31-8-128 kernel: file_update_time+0x123/0x140
Aug 19 15:22:35 ip-172-31-8-128 kernel: ? generic_write_checks+0x61/0xc0
Aug 19 15:22:35 ip-172-31-8-128 kernel:
ext4_buffered_write_iter+0x5a/0x160 [ext4]
Aug 19 15:22:35 ip-172-31-8-128 kernel: new_sync_write+0x11c/0x1b0
Aug 19 15:22:35 ip-172-31-8-128 kernel: vfs_write+0x1bd/0x260
Aug 19 15:22:35 ip-172-31-8-128 kernel: ksys_write+0x5f/0xe0
Aug 19 15:22:35 ip-172-31-8-128 kernel: do_syscall_64+0x33/0x40
Aug 19 15:22:35 ip-172-31-8-128 kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9
Aug 19 15:22:35 ip-172-31-8-128 kernel: RIP: 0033:0x7fd6d8083559
Aug 19 15:22:35 ip-172-31-8-128 kernel: RSP: 002b:00007fd59d7f78e0
EFLAGS: 00000293 ORIG_RAX: 0000000000000001
Aug 19 15:22:35 ip-172-31-8-128 kernel: RAX: ffffffffffffffda RBX:
00007fd580000dd0 RCX: 00007fd6d8083559
Aug 19 15:22:35 ip-172-31-8-128 kernel: RDX: 0000000000004000 RSI:
00007fd580000dd0 RDI: 0000000000000088
Aug 19 15:22:35 ip-172-31-8-128 kernel: RBP: 0000000000004000 R08:
0000000000000000 R09: 0000000000000001
Aug 19 15:22:35 ip-172-31-8-128 kernel: R10: 0000000000000000 R11:
0000000000000293 R12: 00007fd6bfe33b08
Aug 19 15:22:35 ip-172-31-8-128 kernel: R13: 0000000000004000 R14:
00007fd6bfe41480 R15: 00007fd6bfe41320
Also running funclatency BCC script is showing that fsync operations
are taking higher time while having dioread_nolock enabled
dioread_nolock enabled
operation = open
msecs : count distribution
0 -> 1 : 4086 |****************************************|
operation = fsync
msecs : count distribution
0 -> 1 : 0 | |
2 -> 3 : 0 | |
4 -> 7 : 0 | |
8 -> 15 : 92 |******************** |
16 -> 31 : 153 |********************************** |
32 -> 63 : 177 |****************************************|
64 -> 127 : 18 |**** |
128 -> 255 : 77 |***************** |
256 -> 511 : 15 |*** |
512 -> 1023 : 19 |**** |
1024 -> 2047 : 51 |*********** |
2048 -> 4095 : 137 |****************************** |
4096 -> 8191 : 82 |****************** |
8192 -> 16383 : 118 |************************** |
16384 -> 32767 : 104 |*********************** |
32768 -> 65535 : 140 |******************************* |
operation = write
msecs : count distribution
0 -> 1 : 10265 |****************************************|
2 -> 3 : 491 |* |
4 -> 7 : 433 |* |
8 -> 15 : 670 |** |
16 -> 31 : 1043 |**** |
32 -> 63 : 438 |* |
64 -> 127 : 177 | |
128 -> 255 : 129 | |
256 -> 511 : 14 | |
512 -> 1023 : 80 | |
1024 -> 2047 : 24 | |
dioread_lock enabled
operation = fsync
msecs : count distribution
0 -> 1 : 1 | |
2 -> 3 : 115 | |
4 -> 7 : 795 | |
8 -> 15 : 2402 | |
16 -> 31 : 3226 |* |
32 -> 63 : 6271 |** |
64 -> 127 : 109773 |****************************************|
128 -> 255 : 222 | |
operation = write
msecs : count distribution
0 -> 1 : 698243 |****************************************|
2 -> 3 : 967 | |
4 -> 7 : 3233 | |
8 -> 15 : 16189 | |
16 -> 31 : 19443 |* |
32 -> 63 : 47206 |** |
64 -> 127 : 6850 | |
128 -> 255 : 149 | |
operation = open
msecs : count distribution
-> 1 : 8140 |****************************************|
Further tracing is showing that performance degradation we are seeing
is visible in funclatency of add_transaction_credits where we are
waiting until we can add credits for handle to the running
transaction. With dioread_nolock it’s taking on average 154 msec while
0.27 msec with dioread_lock enabled
dioread_nolock enabled
3 warnings generated.
Tracing 1 functions for "add_transaction_credits"... Hit Ctrl-C to end.
^C
nsecs : count distribution
0 -> 1 : 0 | |
2 -> 3 : 0 | |
4 -> 7 : 0 | |
8 -> 15 : 0 | |
16 -> 31 : 0 | |
32 -> 63 : 0 | |
64 -> 127 : 0 | |
128 -> 255 : 12677 |********************|
256 -> 511 : 5374 |******** |
512 -> 1023 : 6898 |********** |
1024 -> 2047 : 4114 |****** |
2048 -> 4095 : 3736 |***** |
4096 -> 8191 : 1954 |*** |
8192 -> 16383 : 329 | |
16384 -> 32767 : 111 | |
32768 -> 65535 : 157 | |
65536 -> 131071 : 191 | |
131072 -> 262143 : 234 | |
262144 -> 524287 : 169 | |
524288 -> 1048575 : 190 | |
1048576 -> 2097151 : 270 | |
2097152 -> 4194303 : 459 | |
4194304 -> 8388607 : 2203 |*** |
8388608 -> 16777215 : 6032 |********* |
16777216 -> 33554431 : 4827 |******* |
33554432 -> 67108863 : 3846 |****** |
67108864 -> 134217727 : 3720 |***** |
134217728 -> 268435455 : 6606 |********** |
268435456 -> 536870911 : 6502 |********** |
536870912 -> 1073741823 : 5072 |******** |
1073741824 -> 2147483647 : 2180 |*** |
2147483648 -> 4294967295 : 229 | |
4294967296 -> 8589934591 : 7 | |
avg = 154580459 nsecs, total: 12084945771325 nsecs, count: 78179
dioread_lock
3 warnings generated.
Tracing 1 functions for "add_transaction_credits"... Hit Ctrl-C to end.
^C
nsecs : count distribution
0 -> 1 : 0 | |
2 -> 3 : 0 | |
4 -> 7 : 0 | |
8 -> 15 : 0 | |
16 -> 31 : 0 | |
32 -> 63 : 0 | |
64 -> 127 : 0 | |
128 -> 255 : 54708 | |
256 -> 511 : 952229 |************ |
512 -> 1023 : 2954850 |****************************************|
1024 -> 2047 : 2833787 |************************************** |
2048 -> 4095 : 2843252 |************************************** |
4096 -> 8191 : 1952274 |************************** |
8192 -> 16383 : 385997 |***** |
16384 -> 32767 : 56495 | |
32768 -> 65535 : 39379 | |
65536 -> 131071 : 27116 | |
131072 -> 262143 : 14277 | |
262144 -> 524287 : 5726 | |
524288 -> 1048575 : 3224 | |
1048576 -> 2097151 : 2192 | |
2097152 -> 4194303 : 6344 | |
4194304 -> 8388607 : 11606 | |
8388608 -> 16777215 : 21528 | |
16777216 -> 33554431 : 42377 | |
33554432 -> 67108863 : 40907 | |
67108864 -> 134217727 : 801 | |
134217728 -> 268435455 : 64 | |
avg = 276573 nsecs, total: 3419652820836 nsecs, count: 12364366
We thought we may be seeing other manifestation for
https://patchwork.ozlabs.org/project/linux-ext4/patch/20220520111402.4252-1-jack@suse.cz/
but unfortunately unsetting EXT4_GET_BLOCKS_PRE_IO in
https://elixir.bootlin.com/linux/v5.10.135/source/fs/ext4/inode.c#L2410didn't
make any difference in reclaiming the performance similar to what it
was with dioread_lock enabled.
Below are the workarounds which helped us reclaiming the performance
back to what it was before commit 244adf6426(ext4: make dioread_nolock
the default)
Mounting using dioread_lock
Enabling nodelalloc and that’s because since commit c8980e1980(ext4:
disable dioread_nolock whenever delayed allocation is disabled)
dioread_nolock will be disabled whenever you disable delayed
allocation.
Increasing the journal size from ext4 128 MiB to 1GiB will also fix the problem.
We know that dioread_nolock is pretty much beneficial for parallel
direct reads as with it enabled we shouldn’t use the DIO read locking
however with buffered writes ext4 will allocate uninitialized extent
before buffer write and convert the extent to initialized after IO
completes and this seems to be the cause behind the reported
regression and we have to note that this should be only beneficial
with extent-based files, it’s also mentioned in the ext4 man page
https://www.kernel.org/doc/Documentation/filesystems/ext4.txt that
dioread_lock is the default which no longer the case since commit
244adf6426(ext4: make dioread_nolock the default) so will need to
update the documentations unless we are going to revert the previously
mentioned commit for the listed reasons.
I think we should revert the previously mentioned commit as this is
clear performance regression otherwise we need to make it explicit in
the commit message that this option has higher journaling overhead and
will require higher journal space if this is working as designed.
I will submit a revert patch for commit 244adf6426(ext4: make
dioread_nolock the default) if that’s what we agreed on after the
discussion
Thank you.
Hazem
Powered by blists - more mailing lists