From: Greg KH <gregkh@linuxfoundation.org>
To: Zbigniew Lukwinski <zbigniew.lukwinski@linux.intel.com>
Cc: zbigelpl@gmail.com, Jan Kara <jack@suse.cz>,
Eric Whitney <enwlinux@gmail.com>,
stable@vger.kernel.org
Subject: Re: [PATCH 1/1] quota: Fix slow quotaoff
Date: Thu, 12 Oct 2023 15:03:27 +0200 [thread overview]
Message-ID: <2023101218-cussed-aside-c623@gregkh> (raw)
In-Reply-To: <20231012122533.1281864-2-zbigniew.lukwinski@linux.intel.com>
On Thu, Oct 12, 2023 at 02:25:33PM +0200, Zbigniew Lukwinski wrote:
> From: Jan Kara <jack@suse.cz>
>
> Eric has reported that commit dabc8b207566 ("quota: fix dqput() to
> follow the guarantees dquot_srcu should provide") heavily increases
> runtime of generic/270 xfstest for ext4 in nojournal mode. The reason
> for this is that ext4 in nojournal mode leaves dquots dirty until the last
> dqput() and thus the cleanup done in quota_release_workfn() has to write
> them all. Due to the way quota_release_workfn() is written this results
> in synchronize_srcu() call for each dirty dquot which makes the dquot
> cleanup when turning quotas off extremely slow.
>
> To be able to avoid synchronize_srcu() for each dirty dquot we need to
> rework how we track dquots to be cleaned up. Instead of keeping the last
> dquot reference while it is on releasing_dquots list, we drop it right
> away and mark the dquot with new DQ_RELEASING_B bit instead. This way we
> can we can remove dquot from releasing_dquots list when new reference to
> it is acquired and thus there's no need to call synchronize_srcu() each
> time we drop dq_list_lock.
>
> References: https://lore.kernel.org/all/ZRytn6CxFK2oECUt@debian-BULLSEYE-live-builder-AMD64
> Reported-by: Eric Whitney <enwlinux@gmail.com>
> Fixes: dabc8b207566 ("quota: fix dqput() to follow the guarantees dquot_srcu should provide")
> CC: stable@vger.kernel.org
> Signed-off-by: Jan Kara <jack@suse.cz>
> ---
> fs/quota/dquot.c | 66 ++++++++++++++++++++++++----------------
> include/linux/quota.h | 4 ++-
> include/linux/quotaops.h | 2 +-
> 3 files changed, 43 insertions(+), 29 deletions(-)
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
</formletter>
next prev parent reply other threads:[~2023-10-12 13:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20231012122533.1281864-1-zbigniew.lukwinski@linux.intel.com>
2023-10-12 12:25 ` [PATCH 1/1] quota: Fix slow quotaoff Zbigniew Lukwinski
2023-10-12 13:03 ` Greg KH [this message]
[not found] <20231012122740.1281902-1-zbigniew.lukwinski@linux.intel.com>
2023-10-12 12:27 ` Zbigniew Lukwinski
2023-10-12 13:03 ` Greg KH
2023-10-12 17:05 ` Greg KH
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=2023101218-cussed-aside-c623@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=enwlinux@gmail.com \
--cc=jack@suse.cz \
--cc=stable@vger.kernel.org \
--cc=zbigelpl@gmail.com \
--cc=zbigniew.lukwinski@linux.intel.com \
/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.