linux-kernel - 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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <81f434bf-f1b7-40d4-aa33-54c2f4869574@gmx.com>
Date: Fri, 16 Aug 2024 17:15:37 +0930
From: Qu Wenruo <quwenruo.btrfs@....com>
To: Ivan Shapovalov <intelfx@...elfx.name>,
 Andrea Gelmini <andrea.gelmini@...il.com>
Cc: linux-btrfs@...r.kernel.org, linux-kernel@...r.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



在 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@...elfx.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