-
- Downloads
pagecache: change locking between mmu and ARC
Now vma_list_mutex is used to protect against races between ARC buffer
mapping by MMU and eviction by ZFS. The problem is that MMU code calls
into ZFS with vma_list_mutex held, so on that path all ZFS related locks
are taken after vma_list_mutex. An attempt to acquire vma_list_mutex
during ARC buffer eviction, while many of the same ZFS locks are already
held, causes deadlock. It was solved by using trylock() and skipping an
eviction if vma_list_mutex cannot be acquired, but it appears that some
mmapped buffers are destroyed not during eviction, but after writeback and
this destruction cannot be delayed. It calls for locking scheme redesign.
This patch introduce arc_lock that have to be held during access to
read_cache. It prevents simultaneous eviction and mapping. arc_lock should
be the most inner lock held on any code path. Code is change to adhere to
this rule. For that the patch replaces ARC_SHARED_BUF flag by new b_mmaped
field. The reason is that access to b_flags field is guarded by hash_lock
and it is impossible to guaranty same order between hash_lock and arc_lock
on all code paths. Dropping the need for hash_lock is a nice solution.
Signed-off-by:
Gleb Natapov <gleb@cloudius-systems.com>
Showing
- bsd/porting/mmu.cc 2 additions, 11 deletionsbsd/porting/mmu.cc
- bsd/porting/mmu.h 1 addition, 2 deletionsbsd/porting/mmu.h
- bsd/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c 9 additions, 23 deletionsbsd/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c
- bsd/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c 3 additions, 9 deletionsbsd/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c
- core/pagecache.cc 79 additions, 62 deletionscore/pagecache.cc
- fs/vfs/vfs_fops.cc 5 additions, 6 deletionsfs/vfs/vfs_fops.cc
- include/osv/pagecache.hh 13 additions, 1 deletioninclude/osv/pagecache.hh
- include/osv/vfs_file.hh 1 addition, 4 deletionsinclude/osv/vfs_file.hh
Loading
Please register or sign in to comment