On Wed, Jun 21, 2023 at 4:27 PM Yu Kuai <yukuai1@xxxxxxxxxxxxxxx> wrote: > > 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 I c. Thanks for the explanation. Regards Xiao