Message-ID: <CACX6voDhGxiyAxaEu0OL+hHFDD9kigso-YVrWTk4jcbvYZKVew@mail.gmail.com>
Date:   Tue, 20 Sep 2022 14:59:34 +0100
From:   hazem ahmed mohamed <hazem.ahmed.abuelfotoh@...il.com>
To:     Thorsten Leemhuis <regressions@...mhuis.info>
Cc:     "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
        "tytso@....edu" <tytso@....edu>,
        "adilger.kernel@...ger.ca" <adilger.kernel@...ger.ca>,
        "regressions@...ts.linux.dev" <regressions@...ts.linux.dev>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        "Mohamed Abuelfotoh, Hazem" <abuehaze@...zon.com>
Subject: Re: Ext4: Buffered random writes performance regression with
 dioread_nolock enabled

Looks like I replied only on Thorsten insteading of replying to all so
moving the discussion to the wider thread for better visibility.

---------- Forwarded message ---------
From: Thorsten Leemhuis <regressions@...mhuis.info>
Date: Tue, 20 Sept 2022 at 14:31
Subject: Re: Ext4: Buffered random writes performance regression with
dioread_nolock enabled
To: hazem ahmed mohamed <hazem.ahmed.abuelfotoh@...il.com>


On 20.09.22 15:21, hazem ahmed mohamed wrote:
> Thanks Thorsten, I am surprised that we merged this commit while it
> has been showing regression since Day-0, unless there is an objection
> I will submit a revert patch until we know what's going on here.

Please keep replies online, then others can learn from the conversation
and weight in. In this particular case I'd explained that a quick revert
after all this time is likely a bad thing, as there is always a risk
that is creates regressions of its own. :-/

Ciao, Thorsten
> On 19.09.22 17:18, hazem ahmed mohamed wrote:
> >
> > I am sending this e-mail to report a performance regression that’s
> > caused by commit 244adf6426(ext4: make dioread_nolock the default) , I
> > am listing the performance regression symptoms below & our analysis
> > for the reported regression.
>
> FWIW, that patch went into v5.6-rc1~113^2~12
>
> And BTW: it seems 0-day back then noticed that 244adf6426 caused a
> performance regression as well, but it seems that was ignored:
> https://lore.kernel.org/all/20201024120829.GK31092@shao2-debian/
>
> Anyway, now to the main reason why I write this mail:
>
> [TLDR: I'm adding this regression report to the list of tracked
> regressions; all text from me you find below is based on a few templates
> paragraphs you might have encountered already already in similar form.]
>
> Thanks for the report. To be sure below issue doesn't fall through the
> cracks unnoticed, I'm adding it to regzbot, my Linux kernel regression
> tracking bot:
>
> #regzbot ^introduced 244adf6426
> #regzbot ignore-activity
>
> This isn't a regression? This issue or a fix for it are already
> discussed somewhere else? It was fixed already? You want to clarify when
> the regression started to happen? Or point out I got the title or
> something else totally wrong? Then just reply -- ideally with also
> telling regzbot about it, as explained here:
> https://linux-regtracking.leemhuis.info/tracked-regression/
>
> Reminder for developers: When fixing the issue, add 'Link:' tags
> pointing to the report (the mail this one replies to), as explained for
> in the Linux kernel's documentation; the webpage mention at the end of
> the last para explains why this is important for tracked regressions.
>
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
>
> P.S.: As the Linux kernel's regression tracker I deal with a lot of
> reports and sometimes miss something important when writing mails like
> this. If that's the case here, don't hesitate to tell me in a public
> reply, it's in everyone's interest to set the public record straight.

Powered by blists - more mailing lists