summaryrefslogtreecommitdiffstats
path: root/drivers/ipack
diff options
context:
space:
mode:
authorDmitry Monakhov <dmonakhov@openvz.org>2016-09-05 23:38:36 -0400
committerTheodore Ts'o <tytso@mit.edu>2016-09-05 23:38:36 -0400
commite22834f0248d0fa841ead6436d6c19f65539dc9c (patch)
tree9dd30fbf51806638dca5aa8b068799303c37e719 /drivers/ipack
parent6ae4c5a69877e5afb6ce63f7d82432133934073a (diff)
downloadop-kernel-dev-e22834f0248d0fa841ead6436d6c19f65539dc9c.zip
op-kernel-dev-e22834f0248d0fa841ead6436d6c19f65539dc9c.tar.gz
ext4: improve ext4lazyinit scalability
ext4lazyinit is a global thread. This thread performs itable initalization under li_list_mtx mutex. It basically does the following: ext4_lazyinit_thread ->mutex_lock(&eli->li_list_mtx); ->ext4_run_li_request(elr) ->ext4_init_inode_table-> Do a lot of IO if the list is large And when new mount/umount arrive they have to block on ->li_list_mtx because lazy_thread holds it during full walk procedure. ext4_fill_super ->ext4_register_li_request ->mutex_lock(&ext4_li_info->li_list_mtx); ->list_add(&elr->lr_request, &ext4_li_info >li_request_list); In my case mount takes 40minutes on server with 36 * 4Tb HDD. Common user may face this in case of very slow dev ( /dev/mmcblkXXX) Even more. If one of filesystems was frozen lazyinit_thread will simply block on sb_start_write() so other mount/umount will be stuck forever. This patch changes logic like follows: - grab ->s_umount read sem before processing new li_request. After that it is safe to drop li_list_mtx because all callers of li_remove_request are holding ->s_umount for write. - li_thread skips frozen SB's Locking order: Mh KOrder is asserted by umount path like follows: s_umount ->li_list_mtx so the only way to to grab ->s_mount inside li_thread is via down_read_trylock xfstests:ext4/023 #PSBM-49658 Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Diffstat (limited to 'drivers/ipack')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud