Re: quota: dqio_mutex design

[Andrew Perepechko <anserper@yandex.ru>]

Hello!

Jan, do you think it makes sense, as an improvement
until the code restructuring, to exit immediately from
ext4_mark_dquot_dirty() if dquot_mark_dquot_dirty()
returns 1?

It seems that in this case we are guaranteed that some
thread is somewhere in the middle of mark_dquot_dirty()
and clear_dquot_dirty(), so it will update the quota file
buffer with the latest dquot data.

That would improve a single user/group scenario like:
thread 1) processing dquot_commit()
thread 2) dirtied dquot and is waiting for dqio_mutex
thread 3, 4, 5 ...) dirtied dquot and are waiting for dqio_mutex

If we exit immediately on dquot dirtying, threads 3, 4, 5, ...
can let thread 2 update the buffer data and themselves
may not block on the mutex.

Thank you,
Andrew


> 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