6.14/regression/bisected - commit b9b588f22a0c somehow broke HW acceleration in the Google Chrome

6.14/regression/bisected - commit b9b588f22a0c somehow broke HW acceleration in the Google Chrome

[Mikhail Gavrilov]

[-- Attachment #1: Type: text/plain, Size: 2036 bytes --]

Hi,
I spotted that Google Chrome started working without HW acceleration.
And git bisect found commit b9b588f22a0c049a14885399e27625635ae6ef91
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Sat Dec 28 12:55:21 2024 -0500

    libfs: Use d_children list to iterate simple_offset directories

    The mtree mechanism has been effective at creating directory offsets
    that are stable over multiple opendir instances. However, it has not
    been able to handle the subtleties of renames that are concurrent
    with readdir.

    Instead of using the mtree to emit entries in the order of their
    offset values, use it only to map incoming ctx->pos to a starting
    entry. Then use the directory's d_children list, which is already
    maintained properly by the dcache, to find the next child to emit.

    One of the sneaky things about this is that when the mtree-allocated
    offset value wraps (which is very rare), looking up ctx->pos++ is
    not going to find the next entry; it will return NULL. Instead, by
    following the d_children list, the offset values can appear in any
    order but all of the entries in the directory will be visited
    eventually.

    Note also that the readdir() is guaranteed to reach the tail of this
    list. Entries are added only at the head of d_children, and readdir
    walks from its current position in that list towards its tail.

    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Link: https://lore.kernel.org/r/20241228175522.1854234-6-cel@kernel.org
    Signed-off-by: Christian Brauner <brauner@kernel.org>

 fs/libfs.c | 84
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--------------------------
 1 file changed, 58 insertions(+), 26 deletions(-)

I tested Google Chrome after reverting commit b9b588f22a0c and ensured
that this fixed the issue.

Machine spec: https://linux-hardware.org/?probe=5810cda90d
I attached below my build config.

Chuck, you, as the author problem commit, can look into this, please?

-- 
Best Regards,
Mike Gavrilov.

[-- Attachment #2: .config.zip --]
[-- Type: application/zip, Size: 67874 bytes --]

[-- Attachment #3: about-gpu-2025-02-12T09-25-55-112Z.zip --]
[-- Type: application/zip, Size: 14923 bytes --]

Re: 6.14/regression/bisected - commit b9b588f22a0c somehow broke HW acceleration in the Google Chrome

[Chuck Lever]

On 2/12/25 9:16 PM, Mikhail Gavrilov wrote:
> Hi,
> I spotted that Google Chrome started working without HW acceleration.
> And git bisect found commit b9b588f22a0c049a14885399e27625635ae6ef91
> Author: Chuck Lever <chuck.lever@oracle.com>
> Date:   Sat Dec 28 12:55:21 2024 -0500
> 
>     libfs: Use d_children list to iterate simple_offset directories
> 
>     The mtree mechanism has been effective at creating directory offsets
>     that are stable over multiple opendir instances. However, it has not
>     been able to handle the subtleties of renames that are concurrent
>     with readdir.
> 
>     Instead of using the mtree to emit entries in the order of their
>     offset values, use it only to map incoming ctx->pos to a starting
>     entry. Then use the directory's d_children list, which is already
>     maintained properly by the dcache, to find the next child to emit.
> 
>     One of the sneaky things about this is that when the mtree-allocated
>     offset value wraps (which is very rare), looking up ctx->pos++ is
>     not going to find the next entry; it will return NULL. Instead, by
>     following the d_children list, the offset values can appear in any
>     order but all of the entries in the directory will be visited
>     eventually.
> 
>     Note also that the readdir() is guaranteed to reach the tail of this
>     list. Entries are added only at the head of d_children, and readdir
>     walks from its current position in that list towards its tail.
> 
>     Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
>     Link: https://lore.kernel.org/r/20241228175522.1854234-6-cel@kernel.org
>     Signed-off-by: Christian Brauner <brauner@kernel.org>
> 
>  fs/libfs.c | 84
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--------------------------
>  1 file changed, 58 insertions(+), 26 deletions(-)
> 
> I tested Google Chrome after reverting commit b9b588f22a0c and ensured
> that this fixed the issue.

I need a simpler reproducer, please. "Chrome stopped working" doesn't
give me anything actionable.


> Machine spec: https://linux-hardware.org/?probe=5810cda90d
> I attached below my build config.
> 
> Chuck, you, as the author problem commit, can look into this, please?


-- 
Chuck Lever

Re: 6.14/regression/bisected - commit b9b588f22a0c somehow broke HW acceleration in the Google Chrome

[Mikhail Gavrilov]

On Thu, Feb 13, 2025 at 7:18 PM Chuck Lever <chuck.lever@oracle.com> wrote:
> I need a simpler reproducer, please. "Chrome stopped working" doesn't
> give me anything actionable.
>

After applying commit b9b588f22a0c, the internal page chrome://gpu/ in
Google Chrome indicates that GPU acceleration is no longer functional.
I apologize, but as I am not a Google Chrome engineer, I have no idea
how to create more clean reproducer code.
I only noticed as a Web browser user that when I scrolled through
pages with a lot of images, Google Chrome got substantially sluggish.
Hopefully, someone from chromium-dev will read my message and help us.

-- 
Best Regards,
Mike Gavrilov.

Re: 6.14/regression/bisected - commit b9b588f22a0c somehow broke HW acceleration in the Google Chrome

[Chuck Lever]

On 2/13/25 10:27 AM, Mikhail Gavrilov wrote:
> On Thu, Feb 13, 2025 at 7:18 PM Chuck Lever <chuck.lever@oracle.com> wrote:
>> I need a simpler reproducer, please. "Chrome stopped working" doesn't
>> give me anything actionable.
>>
> 
> After applying commit b9b588f22a0c, the internal page chrome://gpu/ in
> Google Chrome indicates that GPU acceleration is no longer functional.

The connection between tmpfs and GPU acceleration is ... mysterious ;-)


> I apologize, but as I am not a Google Chrome engineer, I have no idea
> how to create more clean reproducer code.
> I only noticed as a Web browser user that when I scrolled through
> pages with a lot of images, Google Chrome got substantially sluggish.
> Hopefully, someone from chromium-dev will read my message and help us.

Understood. Maybe a better place to start would be for you to file a bug
against Chrome/Chromium, report the same information that you reported
here, and let them dig into it first. I'll still be here waiting for
details... if their issue tracker permits, add me to the Cc list of the
bug report.


-- 
Chuck Lever