Re: quota: dqio_mutex design

[Jan Kara <jack@suse.cz>]

Hi,

On Fri 10-03-17 01:29:22, Andrew Perepechko wrote:
> 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.

Well, it would mostly work, except if process A dirties dquot outside of
transaction (e.g. dquot_set_dqblk()), it could happen that other updates
of dquot inside a running transaction will end up relying on update of
dquot buffer by process A and that may end only in the next transaction
thus breaking the journalling guarantees.

								Honza

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