Hello! On Thu 02-02-17 15:23:44, Andrew Perepechko wrote: > We have a heavy metadata related workload (ext4, quota journalling) > and profiling shows that there's significant dqio_mutex contention. > > From the quota code, it looks like every time dqio_mutex is taken > it protects access to only one quota file. > > Is it possible to split dqio_mutex for each of MAXQUOTAS so that > e.g. 2 parallel dquot_commit()'s can be running for user and group > quota update? Am I missing any dqio_mutex function that requires > dqio_mutex to be monolithic? So we can certainly make dqio_mutex less heavy. Making it per-quota-type would OK but I suspect it will not bring a big benefit. What would likely be more noticeable is if we avoided dqio_mutex for updates of quota information - that should not be that hard to do since we update that in-place and so don't really need the serialization for anything substantial. However we will need some restructuring of the code to make such locking scheme possible in a clean way... Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
