Re: [regression] 5.15 kernel triggering 100x more inode evictions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



First off: David, Filipe, many thx for your answers, that helped me a
lot to get a better picture of the situation!

On 08.04.22 17:55, Filipe Manana wrote:
> On Fri, Apr 08, 2022 at 04:52:22PM +0200, David Sterba wrote:
>> On Fri, Apr 08, 2022 at 12:32:20PM +0200, Thorsten Leemhuis wrote:
>>> Hi, this is your Linux kernel regression tracker. Top-posting for once,
>>> to make this easily accessible to everyone.
>>>
>>> Btrfs maintainers, what's up here? Yes, this regression report was a bit
>>> confusing in the beginning, but Bruno worked on it. And apparently it's
>>> already fixed in 5.16, but still in 5.15. Is this caused by a change
>>> that is to big to backport or something?
>>
>> I haven't identified possible fixes in 5.16 so I can't tell how much
>> backport efforts it could be. As the report is related to performance on
>> package updates, my best guess is that the patches fixing it are those
>> from Filipe related to fsync/logging, and there are several of such
>> improvements in 5.16. Or something else that fixes it indirectly.
> 
> So there's a lot of confusion in the thread,

Yeah, definitely. That basically why I had hoped from a rough assessment
from the btrfs maintainers.

> and the original openSUSE 
> bugzilla [1] is also a bit confusing and large to follow.
> 
> Let me try to make it clear:
> 
> 1) For some reason, outside btrfs' control, inode eviction is triggered
>    a lot on 5.15 kernels in Bruno's test machine when doing package
>    installations/updates with zypper.

So I assume there are no other reports like this? Great!

> [...]

> 6) In short, it is not known what causes the excessive evictions on 5.15
>    on his machine for that specific workload - we don't have a commit to
>    point at and say it caused a regression. [...]

Bruno, under these circumstances I'd say you need to bisect this to get
us closer to the root of the problem (and a fix for it). Sadly that how
it is sometimes, as briefly explained here:

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/admin-guide/reporting-regressions.rst#n140

> This thread is also basically a revamp of an older thread [3].
> 
> [1] https://bugzilla.opensuse.org/show_bug.cgi?id=1193549
> [2] https://lore.kernel.org/linux-btrfs/cover.1642676248.git.fdmanana@xxxxxxxx/
> [3] https://lore.kernel.org/linux-fsdevel/MN2PR20MB251235DDB741CD46A9DD5FAAD24E9@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/

Yeah, but it was this thread that made me aware of the issue -- and just
like [3] it didn't get a single reply from a btrfs maintainer, so I had
to assume the report was ignored. A quick "we have no idea what my cause
this issue and it's the only report with such symptoms so far; could you
please bisect" would have made me happy already. :-D

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)

P.S.: As the Linux kernel's regression tracker I'm getting a lot of
reports on my table. I can only look briefly into most of them and lack
knowledge about most of the areas they concern. I thus unfortunately
will sometimes get things wrong or miss something important. I hope
that's not the case here; if you think it is, don't hesitate to tell me
in a public reply, it's in everyone's interest to set the public record
straight.



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux