Re: quota: dqio_mutex design

[Jan Kara <jack@suse.cz>]

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@suse.com>
SUSE Labs, CR