On Mon, Apr 29, 2013 at 12:29:01AM +0800, Zheng Liu wrote: > From: "Yan, Zheng" <zheng.z.yan@xxxxxxxxx> > > We (Linux Kernel Performance project) found a regression introduced > by commit: > > f7fec032aa ext4: track all extent status in extent status tree > > The commit causes about 20% performance decrease in fio random write > test. Profiler shows that rb_next() uses a lot of CPU time. The call > stack is: > > rb_next > ext4_es_find_delayed_extent > ext4_map_blocks > _ext4_get_block > ext4_get_block_write > __blockdev_direct_IO > ext4_direct_IO > generic_file_direct_write > __generic_file_aio_write > ext4_file_write > aio_rw_vect_retry > aio_run_iocb > do_io_submit > sys_io_submit > system_call_fastpath > io_submit > td_io_getevents > io_u_queued_complete > thread_main > main > __libc_start_main > > The cause is that ext4_es_find_delayed_extent() doesn't have an > upper bound, it keeps searching until a delayed extent is found. > When there are a lots of non-delayed entries in the extent state > tree, ext4_es_find_delayed_extent() may uses a lot of CPU time. > > Reported-by: LKP project <lkp@xxxxxxxxxxxxxxx> > Signed-off-by: Yan, Zheng <zheng.z.yan@xxxxxxxxx> > Signed-off-by: Zheng Liu <wenqing.lz@xxxxxxxxxx> > Cc: "Theodore Ts'o" <tytso@xxxxxxx> Thanks, applied. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
