From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Ivan Shapovalov <intelfx@intelfx.name>,
Andrea Gelmini <andrea.gelmini@gmail.com>
Cc: linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: 6.10/regression/bisected - after f1d97e769152 I spotted increased execution time of the kswapd0 process and symptoms as if there is not enough memory
Date: Fri, 16 Aug 2024 17:15:37 +0930 [thread overview]
Message-ID: <81f434bf-f1b7-40d4-aa33-54c2f4869574@gmx.com> (raw)
In-Reply-To: <7fca93ba155921cd3d32678899bbfcea58d23da3.camel@intelfx.name>
在 2024/8/16 16:17, Ivan Shapovalov 写道:
> On 2024-08-16 at 08:42 +0200, Andrea Gelmini wrote:
>> Il giorno ven 16 ago 2024 alle ore 01:17 <intelfx@intelfx.name> ha scritto:
>>> Can we please have it reverted on the basis of this severe regression,
>>> until a better solution is found?
>>
>> To disable the shrinker I simply remove two items:
>>
>> diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
>> index f05cce7c8b8d..4f958ba61e0e 100644
>> --- a/fs/btrfs/super.c
>> +++ b/fs/btrfs/super.c
>> @@ -2410,8 +2410,6 @@ static const struct super_operations btrfs_super_ops = {
>> .statfs = btrfs_statfs,
>> .freeze_fs = btrfs_freeze,
>> .unfreeze_fs = btrfs_unfreeze,
>> - .nr_cached_objects = btrfs_nr_cached_objects,
>> - .free_cached_objects = btrfs_free_cached_objects,
>> };
>>
>> static const struct file_operations btrfs_ctl_fops = {
>>
>> This is from my thread with Filipe about same topic you can find in
>> the mailing list archive.
>
> Yes, that's what I did locally so far, on those systems that I _can_
> run custom kernels on. The others I had to downgrade to 6.9 for the
> time being. So I do have a vested interest in this being resolved in
> the mainline/stable tree :-)
>
That's the most straightforward way to revert to the previous behavior.
Or you can try this patch, which is less obvious but should do the same
thing:
https://lore.kernel.org/linux-btrfs/09ca70ddac244d13780bd82866b8b708088362fb.1723770634.git.wqu@suse.com/T/#u
Meanwhile after looking into how XFS triggers its reclaim, I believe we
should not even bother using those callbacks.
XFS handles the trigger by making sure there is only one reclaim
workload queued, and the workload always delay 18s by default.
So for btrfs, I believe it's better to do the reclaim in the cleaner thread.
Will craft a proper fix for you guys to test, and since Filipe is on
vacation, we may go disable the reclaim workload for now.
Thanks,
Qu
next prev parent reply other threads:[~2024-08-16 7:45 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-25 20:56 6.10/regression/bisected - after f1d97e769152 I spotted increased execution time of the kswapd0 process and symptoms as if there is not enough memory Mikhail Gavrilov
2024-06-26 10:48 ` Filipe Manana
2024-06-26 14:16 ` Mikhail Gavrilov
2024-07-01 9:30 ` Filipe Manana
2024-07-02 14:13 ` Mikhail Gavrilov
2024-07-02 17:22 ` Filipe Manana
2024-07-02 19:46 ` Chris Murphy
2024-07-03 10:32 ` Filipe Manana
2024-07-03 10:31 ` Filipe Manana
2024-07-03 10:44 ` Filipe Manana
2024-07-03 21:07 ` Andrea Gelmini
2024-07-04 9:48 ` Filipe Manana
2024-07-04 9:56 ` Filipe Manana
2024-07-04 10:50 ` Mikhail Gavrilov
2024-07-04 13:33 ` Andrea Gelmini
2024-07-04 13:47 ` Andrea Gelmini
2024-07-04 14:48 ` Andrea Gelmini
2024-07-04 17:25 ` Filipe Manana
2024-07-04 17:31 ` Filipe Manana
2024-07-04 22:15 ` Andrea Gelmini
2024-07-04 22:23 ` Andrea Gelmini
2024-07-05 11:00 ` Filipe Manana
2024-07-05 6:30 ` Andrea Gelmini
2024-07-05 11:06 ` Filipe Manana
2024-07-05 18:36 ` Mikhail Gavrilov
2024-07-05 23:09 ` Filipe Manana
2024-07-06 0:11 ` Andrea Gelmini
2024-07-06 12:07 ` Andrea Gelmini
2024-07-06 17:37 ` Filipe Manana
2024-07-07 9:41 ` Filipe Manana
2024-07-07 10:15 ` Andrea Gelmini
2024-07-07 10:28 ` Filipe Manana
2024-07-07 11:15 ` Andrea Gelmini
2024-07-07 12:10 ` Filipe Manana
2024-07-07 11:35 ` Mikhail Gavrilov
2024-07-07 12:15 ` Filipe Manana
2024-07-07 19:16 ` Mikhail Gavrilov
2024-07-08 14:15 ` Filipe Manana
2024-07-10 9:24 ` Mikhail Gavrilov
2024-07-10 10:53 ` Filipe Manana
2024-08-11 8:08 ` Jannik Glückert
2024-08-11 15:33 ` Filipe Manana
2024-08-14 21:24 ` Jannik Glückert
2024-08-15 22:21 ` intelfx
2024-08-15 23:17 ` intelfx
2024-08-16 0:02 ` David Sterba
2024-08-16 6:42 ` Andrea Gelmini
2024-08-16 6:47 ` Ivan Shapovalov
2024-08-16 7:45 ` Qu Wenruo [this message]
2024-08-16 10:58 ` Filipe Manana
2024-08-16 11:16 ` Ivan Shapovalov
2024-09-26 13:45 ` Filipe Manana
2024-07-04 11:18 ` Andrea Gelmini
2024-07-04 16:38 ` Filipe Manana
2024-07-04 22:32 ` Qu Wenruo
2024-07-05 6:18 ` Andrea Gelmini
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=81f434bf-f1b7-40d4-aa33-54c2f4869574@gmx.com \
--to=quwenruo.btrfs@gmx.com \
--cc=andrea.gelmini@gmail.com \
--cc=intelfx@intelfx.name \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox