From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de ([195.135.220.15]:38555 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752881AbdCMIvO (ORCPT ); Mon, 13 Mar 2017 04:51:14 -0400 Date: Mon, 13 Mar 2017 09:44:55 +0100 From: Jan Kara To: Andrew Perepechko Cc: Jan Kara , linux-fsdevel@vger.kernel.org Subject: Re: quota: dqio_mutex design Message-ID: <20170313084455.GA17897@quack2.suse.cz> References: <10928956.Fla3vXZ7d9@panda> <20170303100842.GB4373@quack2.suse.cz> <2044807.uqPyBdneMn@panda> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2044807.uqPyBdneMn@panda> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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 SUSE Labs, CR