From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B1342C4332F for ; Fri, 2 Dec 2022 08:46:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 234AB6B0074; Fri, 2 Dec 2022 03:46:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1E52F6B0075; Fri, 2 Dec 2022 03:46:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 086C56B0078; Fri, 2 Dec 2022 03:46:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id E8D9E6B0074 for ; Fri, 2 Dec 2022 03:46:56 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id C285B141333 for ; Fri, 2 Dec 2022 08:46:56 +0000 (UTC) X-FDA: 80196736032.17.7C42DF7 Received: from wp530.webpack.hosteurope.de (wp530.webpack.hosteurope.de [80.237.130.52]) by imf20.hostedemail.com (Postfix) with ESMTP id 31DFF1C000F for ; Fri, 2 Dec 2022 08:46:55 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=none; spf=pass (imf20.hostedemail.com: domain of regressions@leemhuis.info designates 80.237.130.52 as permitted sender) smtp.mailfrom=regressions@leemhuis.info; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669970816; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+3B45PUPfweBYaidzzAidbXobZVMj444soprgqtVkfw=; b=nchWzKacfLG39GKpR6FNve3boHeaRh/pVR0cVudZG4qvkD1lecZ68cGubuFy/rvEMJbrNa Ako2gomcMN0FZydiqdhA1md+F14HKML3xU5ghKgX2rp1jKmtu/HCurgonMflyQSi69DL03 66rjXshYzS5nUx7ZaAeRXcF/BhsK1Lc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669970816; a=rsa-sha256; cv=none; b=bhJk/D3iOdk2O6VrvH8VbJUnFhLLkLLWOS9g0XIglwjtAw3fDWqKr3qaAt8TKk7UCMzkzI 1x2MOatOif/oVi5Vsgn+t7R0kz+YD2yFkmbAioOfGMsBzNC7mPwsjr1zmwpO/o2szM96U7 U3jvtHIx+vTa+UOLbiTehFsgE+dY3po= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=none; spf=pass (imf20.hostedemail.com: domain of regressions@leemhuis.info designates 80.237.130.52 as permitted sender) smtp.mailfrom=regressions@leemhuis.info; dmarc=none Received: from [2a02:8108:963f:de38:eca4:7d19:f9a2:22c5]; authenticated by wp530.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1p11h3-0005H4-2F; Fri, 02 Dec 2022 09:46:49 +0100 Message-ID: Date: Fri, 2 Dec 2022 09:46:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Subject: Re: [mm] f35b5d7d67: will-it-scale.per_process_ops -95.5% regression Content-Language: en-US, de-DE To: Andrew Morton , Rik van Riel Cc: Yang Shi , "Huang, Ying" , kernel test robot , lkp@lists.01.org, lkp@intel.com, Matthew Wilcox , linux-kernel@vger.kernel.org, linux-mm@kvack.org, feng.tang@intel.com, zhengjun.xing@linux.intel.com, fengwei.yin@intel.com, Nathan Chancellor References: <202210181535.7144dd15-yujie.liu@intel.com> <87edv4r2ip.fsf@yhuang6-desk2.ccr.corp.intel.com> <871qr3nkw2.fsf@yhuang6-desk2.ccr.corp.intel.com> <366045a27a96e01d0526d63fd78d4f3c5d1f530b.camel@surriel.com> <07adee081a70c2b4b44d9bf93a0ad3142e091086.camel@surriel.com> <20221201132237.c55c4bd07ba44463b146882e@linux-foundation.org> From: Thorsten Leemhuis In-Reply-To: <20221201132237.c55c4bd07ba44463b146882e@linux-foundation.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-bounce-key: webpack.hosteurope.de;regressions@leemhuis.info;1669970816;54f2efb8; X-HE-SMSGID: 1p11h3-0005H4-2F X-Rspam-User: X-Rspamd-Queue-Id: 31DFF1C000F X-Stat-Signature: t1uty46j4bpdufqiyb96pr1s6ogi9i31 X-Rspamd-Server: rspam01 X-Spamd-Result: default: False [-2.20 / 9.00]; BAYES_HAM(-3.00)[100.00%]; SUBJECT_HAS_UNDERSCORES(1.00)[]; R_SPF_ALLOW(-0.20)[+ip4:80.237.130.0/24]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCPT_COUNT_TWELVE(0.00)[14]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_SIGNED(0.00)[hostedemail.com:s=arc-20220608:i=1]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[leemhuis.info]; ARC_NA(0.00)[] X-HE-Tag: 1669970815-997772 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 01.12.22 22:22, Andrew Morton wrote: > On Thu, 01 Dec 2022 15:29:41 -0500 Rik van Riel 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)