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  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]
Date:   Tue, 20 Sep 2022 14:59:34 +0100
From:   hazem ahmed mohamed <>
To:     Thorsten Leemhuis <>
Cc:     "" <>,
        "" <>,
        "" <>,
        "" <>,
        "" <>,
        "Mohamed Abuelfotoh, Hazem" <>
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 <>
Date: Tue, 20 Sept 2022 at 14:31
Subject: Re: Ext4: Buffered random writes performance regression with
dioread_nolock enabled
To: hazem ahmed mohamed <>

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:
> 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:
> 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