On Sun, May 26, 2013 at 10:52:07PM +0200, Roger Pau Monné wrote: > On 26/05/13 22:20, Jilles Tjoelker wrote: > > Instead of a pause() that may be too short or too long, how about > > waiting for the necessary lock? In other words, replace the kern_yield() > > call with VI_LOCK(vp); VI_UNLOCK(vp);. This is also the usual approach > > to acquire two locks without imposing an order between them.
> Since there might be more than one locked vnode, waiting on a specific > locked vnode seemed rather arbitrary, but I agree that the pause is also > rather arbitrary. > Also, can we be sure that the v_interlock mutex will not be destroyed > while the syncer process is waiting for it to be unlocked? I think this is a major problem. My idea was too easy and will not work. That said, the code in mnt_vnode_next_active() appears to implement some sort of adaptive spinning for SMP. It tries VI_TRYLOCK for 200ms (default value of hogticks) and then yields. This is far too long for a mutex lock and if it takes that long it means that either the thread owning the lock is blocked by us somehow or someone is abusing a mutex to work like a sleepable lock such as by spinning or DELAY. Given that it has been spinning for 200ms, it is not so bad to pause for one additional microsecond. The adaptive spinning was added fairly recently, so apparently it happens fairly frequently that VI_TRYLOCK fails transiently. Unfortunately, the real adaptive spinning code cannot be used because it will spin forever as long as the thread owning v_interlock is running, including when that is because it is spinning for vnode_free_list_mtx. Perhaps we can try to VI_TRYLOCK a certain number of times. It is also possible to check the contested bit of vnode_free_list_mtx (sys/netgraph/netflow/netflow.c does something similar) and stop spinning in that case. A cpu_spinwait() invocation should also be added to the spin loop. -- Jilles Tjoelker _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
