All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Andrew Perepechko <anserper@yandex.ru>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: quota: dqio_mutex design
Date: Fri, 3 Mar 2017 11:08:42 +0100	[thread overview]
Message-ID: <20170303100842.GB4373@quack2.suse.cz> (raw)
In-Reply-To: <10928956.Fla3vXZ7d9@panda>

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

  reply	other threads:[~2017-03-03 11:23 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-02 12:23 quota: dqio_mutex design Andrew Perepechko
2017-03-03 10:08 ` Jan Kara [this message]
2017-03-09 22:29   ` Andrew Perepechko
2017-03-13  8:44     ` Jan Kara
2017-06-21 10:52   ` Jan Kara
     [not found]     ` <4181747.CBilgxvOab@panda>
2017-08-01 13:02       ` Jan Kara
2017-08-02 16:25         ` Jan Kara
2017-08-02 17:52           ` Andrew Perepechko
2017-08-03 11:09             ` Jan Kara
2017-08-03 11:31             ` Wang Shilong
2017-08-03 12:24               ` Andrew Perepechko
2017-08-03 13:19                 ` Wang Shilong
2017-08-03 13:41                   ` Andrew Perepechko
2017-08-03 13:55                     ` Andrew Perepechko
2017-08-03 14:23                       ` Jan Kara
2017-08-03 14:36               ` Jan Kara
2017-08-03 14:39                 ` Wang Shilong
2017-08-08 16:06                   ` Jan Kara
2017-08-14  3:24                     ` Wang Shilong
2017-08-14  3:28                       ` Wang Shilong
2017-08-14  3:53                       ` Wang Shilong
2017-08-14  8:22                         ` Jan Kara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170303100842.GB4373@quack2.suse.cz \
    --to=jack@suse.cz \
    --cc=anserper@yandex.ru \
    --cc=linux-fsdevel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.