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@xxxxxxxx> SUSE Labs, CR
