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
| ||
|
Date: Fri, 2 Dec 2022 09:46:48 +0100 From: Thorsten Leemhuis <regressions@...mhuis.info> To: Andrew Morton <akpm@...ux-foundation.org>, Rik van Riel <riel@...riel.com> Cc: Yang Shi <shy828301@...il.com>, "Huang, Ying" <ying.huang@...el.com>, kernel test robot <yujie.liu@...el.com>, lkp@...ts.01.org, lkp@...el.com, Matthew Wilcox <willy@...radead.org>, linux-kernel@...r.kernel.org, linux-mm@...ck.org, feng.tang@...el.com, zhengjun.xing@...ux.intel.com, fengwei.yin@...el.com, Nathan Chancellor <nathan@...nel.org> Subject: Re: [mm] f35b5d7d67: will-it-scale.per_process_ops -95.5% regression On 01.12.22 22:22, Andrew Morton wrote: > On Thu, 01 Dec 2022 15:29:41 -0500 Rik van Riel <riel@...riel.com> wrote: >> On Thu, 2022-12-01 at 19:33 +0100, Thorsten Leemhuis wrote: >>> On 28.11.22 07:40, Nathan Chancellor wrote: >>> I wonder what we should do about below performance regression. Is >>> reverting the culprit now and reapplying it later together with a fix >>> a >>> viable option? Or was anything done/is anybody doing something >>> already >>> to address the problem and I just missed it? >> >> The changeset in question speeds up kernel compiles with >> GCC, as well as the runtime speed of other programs, due >> to being able to use THPs more. However, it slows down kernel >> compiles with clang, due to ... something clang does. >> >> I have not figured out what that something is yet. >> >> I don't know if I have the wrong version of clang here, >> but I have not seen any smoking gun at all when tracing >> clang system calls. I see predominantly small mmap and >> unmap calls, and nothing that even triggers 2MB alignment. > > 2.8% speedup for gcc is nice. Massive slowdown in the malloc banchmark > and in LLVM/clang is very bad - we don't know what other userspace will > be so affected. > > So I think we revert until this is fully understood. Andrew, many thx for taking care of this. While at it let me please get a small process issue of my chest: What beverage of choice do I have to offer you to make you in the future include 'Link:' tags linking to the report(s) when you add reverts like the one for this issue? My regression tracking bot heavily relies on them, that's why I care. And our documentation (see [1]) also says that they should be used. But the main reason why I ask in this particular case is different: They in cases like afaics are especially helpful, as they make life a whole lot easier for future code archeologists. And I guess that's not something theoretical in this case, as I assume the patch that triggered the issue will come back sooner or later -- and then those links will help a lot to find this thread. Which is also why Linus really wants to see them: https://lore.kernel.org/all/CAHk-=wjMmSZzMJ3Xnskdg4+GGz=5p5p+GSYyFBTh0f-DgvdBWg@mail.gmail.com/ https://lore.kernel.org/all/CAHk-=wgs38ZrfPvy=nOwVkVzjpM3VFU1zobP37Fwd_h9iAD5JQ@mail.gmail.com/ https://lore.kernel.org/all/CAHk-=wjxzafG-=J8oT30s7upn4RhBs6TX-uVFZ5rME+L5_DoJA@mail.gmail.com/ Ciao, Thorsten [1] see Documentation/process/submitting-patches.rst (http://docs.kernel.org/process/submitting-patches.html) and Documentation/process/5.Posting.rst (https://docs.kernel.org/process/5.Posting.html)
Powered by blists - more mailing lists