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 X-Spam-Level: X-Spam-Status: No, score=-7.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D8F0BC2D0ED for ; Thu, 26 Mar 2020 08:34:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B9760207FC for ; Thu, 26 Mar 2020 08:34:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727881AbgCZIeW (ORCPT ); Thu, 26 Mar 2020 04:34:22 -0400 Received: from mga04.intel.com ([192.55.52.120]:44735 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727866AbgCZIeV (ORCPT ); Thu, 26 Mar 2020 04:34:21 -0400 IronPort-SDR: RVr/sKGyhxIMdz6HpIaaMhZpfgGs268wiRdrLx+0F/vTNiomitmxvpQm9rcyLdfPmw+VnHiadS Pn7Gy77wADBw== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Mar 2020 01:34:21 -0700 IronPort-SDR: nly9xD30xpsmGWYFWXpCQfSK56dqJFIPOST3nuhEheHKExNfIQ5XgPc3HXfYowGvGJpdixXyaW B8k9bFVtCr9w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,307,1580803200"; d="scan'208";a="446919804" Received: from shao2-debian.sh.intel.com (HELO localhost) ([10.239.13.3]) by fmsmga005.fm.intel.com with ESMTP; 26 Mar 2020 01:34:13 -0700 Date: Thu, 26 Mar 2020 16:33:55 +0800 From: kernel test robot To: Thomas Gleixner Cc: Andy Shevchenko , LKML , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , Greg Kroah-Hartman , Mark Gross , Tony Luck , "Rafael J. Wysocki" , Viresh Kumar , Linux PM , Srinivas Pandruvada , Len Brown , Paolo Bonzini , Darren Hart , Andy Shevchenko , ACPI Devel Maling List , linux-edac@vger.kernel.org, Platform Driver , Jean Delvare , Guenter Roeck , linux-hwmon@vger.kernel.org, Zhang Rui , Daniel Lezcano , Amit Kucheria , Chanwoo Choi , Jacob Pan , Adrian Hunter , Ulf Hansson , linux-mmc , Bjorn Helgaas , linux-pci@vger.kernel.org, Takashi Iwai , ALSA Development Mailing List , Herbert Xu , "David S. Miller" , linux-crypto , lkp@lists.01.org Subject: Re: [cpufreq] 06c4d00466: will-it-scale.per_process_ops -53.4% regression Message-ID: <20200326083355.GO11705@shao2-debian> References: <20200320131509.564059710@linutronix.de> <20200324060124.GC11705@shao2-debian> <43a4189a-7153-18e8-4657-4a4400002c05@intel.com> <87zhc4ybbt.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87zhc4ybbt.fsf@nanos.tec.linutronix.de> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-mmc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mmc@vger.kernel.org On Wed, Mar 25, 2020 at 11:32:06AM +0100, Thomas Gleixner wrote: > Rong Chen writes: > > On 3/24/20 6:24 PM, Andy Shevchenko wrote: > >> On Tue, Mar 24, 2020 at 8:02 AM kernel test robot wrote: > >>> Greeting, > >>> > >>> FYI, we noticed a -53.4% regression of will-it-scale.per_process_ops due to commit: > >>> commit: 06c4d00466eb374841bc84c39af19b3161ff6917 ("[patch 09/22] cpufreq: Convert to new X86 CPU match macros") > >>> url: https://github.com/0day-ci/linux/commits/Thomas-Gleixner/x86-devicetable-Move-x86-specific-macro-out-of-generic-code/20200321-031729 > >>> base: https://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git linux-next > >>> > >>> in testcase: will-it-scale > >>> on test machine: 4 threads Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz with 8G memory > >>> with following parameters: > >> > >> drivers/cpufreq/speedstep-centrino.c change missed the terminator, > >> perhaps it's a culprit, because I don't believe removing dups and > >> reordering lines may affect this. > >> Can you restore terminator there and re-test? > >> > > > > I have retested with the change, but it has no effect on the performance. > > Bah. The binary equivalence testing detected this, but I obvioulsy > missed it. Delta fix below. > > Thanks, > > tglx > > 8<-------------- > --- a/drivers/cpufreq/intel_pstate.c > +++ b/drivers/cpufreq/intel_pstate.c > @@ -2727,7 +2727,7 @@ static inline void intel_pstate_request_ > > #define X86_MATCH_HWP(model, hwp_mode) \ > X86_MATCH_VENDOR_FAM_MODEL_FEATURE(INTEL, 6, INTEL_FAM6_##model, \ > - X86_FEATURE_APERFMPERF, hwp_mode) > + X86_FEATURE_HWP, hwp_mode) > > static const struct x86_cpu_id hwp_support_ids[] __initconst = { > X86_MATCH_HWP(BROADWELL_X, INTEL_PSTATE_HWP_BROADWELL), Hi Thomas, The patch can fix the regression: commit: 06c4d00466 ("cpufreq: Convert to new X86 CPU match macros") d369f9be1a ("the fix patch") 06c4d00466eb3748 d369f9be1ad1e22da4e8f03557 testcase/testparams/testbox ---------------- -------------------------- --------------------------- %stddev change %stddev \ | \ 93200 114% 199599 will-it-scale/performance-process-16-read2-ucode=0x21/lkp-ivb-d02 93200 114% 199599 GEO-MEAN will-it-scale.per_process_ops Best Regards, Rong Chen