Hi,
在 2023/06/21 16:05, Xiao Ni 写道:
On Fri, Jun 16, 2023 at 8:27 PM Yu Kuai <yukuai1@xxxxxxxxxxxxxxx> wrote:
Hi,
在 2023/06/16 19:51, Ali Gholami Rudi 写道:
Thanks for testing!
Perf's output:
+ 93.79% 0.09% fio [kernel.kallsyms] [k] entry_SYSCALL_64_after_hwframe
+ 92.89% 0.05% fio [kernel.kallsyms] [k] do_syscall_64
+ 86.59% 0.07% fio [kernel.kallsyms] [k] __x64_sys_io_submit
- 85.61% 0.10% fio [kernel.kallsyms] [k] io_submit_one
- 85.51% io_submit_one
- 47.98% aio_read
- 46.18% blkdev_read_iter
- 44.90% __blkdev_direct_IO_async
- 41.68% submit_bio_noacct_nocheck
- 41.50% __submit_bio
- 18.76% md_handle_request
- 18.71% raid10_make_request
- 18.54% raid10_read_request
16.54% read_balance
There is not any spin_lock in fast path anymore. Now, looks like
main cost is raid10 io path now(read_balance looks worth
investigation, 16.54% is too much), and for a real device with ms
io latency, I think latency in io path may not matter.
Hi Kuai
Cool. And I noticed you mentioned 'fast path' in many places. What's
the meaning of 'fast path'? Does it mean the path that i/os are
submitting?
Yes, and fast path means the case all resources is available and io can
be submitted to device without blocking.
There should be no spin_lock or atomic ops in fast path, otherwise io
performance will be affected.
Thanks,
Kuai
Regards
Xiao
.
