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
