On Fri 03-03-17 11:08:42, Jan Kara wrote: > 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... So I'm experimenting with some patches. However I have trouble creating a workload where quota updates would show significant overhead. Can you share which workload is problematic for you? Thanks! Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
