* Re: [LKP] Re: [io_uring] 584b0180f0: phoronix-test-suite.fio.SequentialWrite.IO_uring.Yes.Yes.1MB.DefaultTestDirectory.mb_s -10.2% regression
2022-05-27 13:50 ` [io_uring] 584b0180f0: phoronix-test-suite.fio.SequentialWrite.IO_uring.Yes.Yes.1MB.DefaultTestDirectory.mb_s -10.2% regression Jens Axboe
@ 2022-06-14 1:54 ` Yin Fengwei
0 siblings, 0 replies; 2+ messages in thread
From: Yin Fengwei @ 2022-06-14 1:54 UTC (permalink / raw)
To: Jens Axboe, kernel test robot
Cc: LKML, io-uring, lkp, lkp, guobing.chen, ming.a.chen, frank.du,
Shuhua.Fan, wangyang.guo, Wenhuan.Huang, jessica.ji, shan.kang,
guangli.li, tiejun.li, yu.ma, dapeng1.mi, jiebin.sun, gengxin.xie,
fan.zhao
On 5/27/2022 9:50 PM, Jens Axboe wrote:
> On 5/27/22 3:24 AM, kernel test robot wrote:
>>
>>
>> Greeting,
>>
>> FYI, we noticed a -10.2% regression of phoronix-test-suite.fio.SequentialWrite.IO_uring.Yes.Yes.1MB.DefaultTestDirectory.mb_s due to commit:
>>
>>
>> commit: 584b0180f0f4d67d7145950fe68c625f06c88b10 ("io_uring: move read/write file prep state into actual opcode handler")
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>>
>> in testcase: phoronix-test-suite
>> on test machine: 96 threads 2 sockets Intel(R) Xeon(R) Gold 6252 CPU @ 2.10GHz with 512G memory
>> with following parameters:
>>
>> test: fio-1.14.1
>> option_a: Sequential Write
>> option_b: IO_uring
>> option_c: Yes
>> option_d: Yes
>> option_e: 1MB
>> option_f: Default Test Directory
>> cpufreq_governor: performance
>> ucode: 0x500320a
>>
>> test-description: The Phoronix Test Suite is the most comprehensive testing and benchmarking platform available that provides an extensible framework for which new tests can be easily added.
>> test-url: http://www.phoronix-test-suite.com/
>
> I'm a bit skeptical on this, but I'd like to try and run the test case.
> Since it's just a fio test case, why can't I find it somewhere? Seems
> very convoluted to have to setup lkp-tests just for this. Besides, I
> tried, but it doesn't work on aarch64...
>
We re-run the test and still could get exactly same test result. We noticed
following info from perf profile:
14.40 ± 21% +71.3 85.71 ± 2% perf-profile.calltrace.cycles-pp.io_wqe_worker.ret_from_fork
14.25 ± 21% +71.4 85.64 ± 2% perf-profile.calltrace.cycles-pp.io_worker_handle_work.io_wqe_worker.ret_from_fork
14.23 ± 21% +71.4 85.63 ± 2% perf-profile.calltrace.cycles-pp.io_issue_sqe.io_wq_submit_work.io_worker_handle_work.io_wqe_worker.ret_from_fork
14.23 ± 21% +71.4 85.64 ± 2% perf-profile.calltrace.cycles-pp.io_wq_submit_work.io_worker_handle_work.io_wqe_worker.ret_from_fork
14.22 ± 21% +71.4 85.63 ± 2% perf-profile.calltrace.cycles-pp.io_write.io_issue_sqe.io_wq_submit_work.io_worker_handle_work.io_wqe_worker
14.10 ± 21% +71.5 85.62 ± 2% perf-profile.calltrace.cycles-pp.ext4_buffered_write_iter.io_write.io_issue_sqe.io_wq_submit_work.io_worker_handle_work
0.00 +80.9 80.92 ± 2% perf-profile.calltrace.cycles-pp.osq_lock.rwsem_optimistic_spin.rwsem_down_write_slowpath.ext4_buffered_write_iter.io_write
0.00 +83.0 82.99 ± 2% perf-profile.calltrace.cycles-pp.rwsem_optimistic_spin.rwsem_down_write_slowpath.ext4_buffered_write_iter.io_write.io_issue_sqe
0.00 +83.6 83.63 ± 2% perf-profile.calltrace.cycles-pp.rwsem_down_write_slowpath.ext4_buffered_write_iter.io_write.io_issue_sqe.io_wq_submit_work
The above operations takes more time with the patch applied.
It looks like the inode lock contention raised a lot with
the patch.
Frankly, we can't connect this behavior with the patch. Just
list here for your information. Thanks.
Regards
Yin, Fengwei
^ permalink raw reply [flat|nested] 2+ messages in thread