From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from forward4p.cmail.yandex.net ([77.88.31.19]:40743 "EHLO forward4p.cmail.yandex.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751875AbdCIWhE (ORCPT ); Thu, 9 Mar 2017 17:37:04 -0500 From: Andrew Perepechko To: Jan Kara Cc: linux-fsdevel@vger.kernel.org Subject: Re: quota: dqio_mutex design Date: Fri, 10 Mar 2017 01:29:22 +0300 Message-ID: <2044807.uqPyBdneMn@panda> In-Reply-To: <20170303100842.GB4373@quack2.suse.cz> References: <10928956.Fla3vXZ7d9@panda> <20170303100842.GB4373@quack2.suse.cz> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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