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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 79396C433F5 for ; Wed, 11 May 2022 01:58:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240924AbiEKB6h (ORCPT ); Tue, 10 May 2022 21:58:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53270 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240919AbiEKB6e (ORCPT ); Tue, 10 May 2022 21:58:34 -0400 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A25354A3CF for ; Tue, 10 May 2022 18:58:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1652234311; x=1683770311; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=iN1Fkrsl+QmnVro/odOcjaQezWH2OHwK6t9GN9q9rpM=; b=VKrUYYtFQyc1FZnuoA126Y7M5dXwQ0ej8nhJRbBjNMsBx+bObJfQqWNY u23nPPpQyDehi+euRW3qcl2S40ccO1TdNiyd/grGCy5KKtd2C7TExCWDI sTUBSHibGn31v/k4RRjzWYVJ2/r8Oo6r+QT1QHfaetZq5131xDx/FWhYd JkMGQTl1dDCG4yX/0722iAtWDbRtHcmQXAuDUORQYiKJNjgx8OlAYtIjq po57DP3A0ZHulk/84bHA4AlWAm4UJEipW1tR6C3aOwuFrzlVon+OdrIls LEgAP6gEaCIIYRA3czRNu8PxeIbvaCPoLUw6hK/aJKv8SlpTUzUgETDpb g==; X-IronPort-AV: E=McAfee;i="6400,9594,10343"; a="268393321" X-IronPort-AV: E=Sophos;i="5.91,215,1647327600"; d="scan'208";a="268393321" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 May 2022 18:58:31 -0700 X-IronPort-AV: E=Sophos;i="5.91,215,1647327600"; d="scan'208";a="593856606" Received: from rliu1-mobl1.ccr.corp.intel.com ([10.254.213.20]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 May 2022 18:58:26 -0700 Message-ID: <41c08a5371957acac5310a2e608b2e42bd231558.camel@intel.com> Subject: Re: [mm/page_alloc] f26b3fa046: netperf.Throughput_Mbps -18.0% regression From: "ying.huang@intel.com" To: Linus Torvalds , Waiman Long , Peter Zijlstra , Will Deacon Cc: Aaron Lu , Mel Gorman , kernel test robot , Vlastimil Babka , Dave Hansen , Jesper Dangaard Brouer , Michal Hocko , Andrew Morton , LKML , lkp@lists.01.org, kernel test robot , Feng Tang , Zhengjun Xing , fengwei.yin@intel.com Date: Wed, 11 May 2022 09:58:23 +0800 In-Reply-To: References: <20220420013526.GB14333@xsang-OptiPlex-9020> <7d20a9543f69523cfda280e3f5ab17d68db037ab.camel@intel.com> <37dac785a08e3a341bf05d9ee35f19718ce83d26.camel@intel.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2022-05-10 at 11:05 -0700, Linus Torvalds wrote: > [ Adding locking people in case they have any input ] > > On Mon, May 9, 2022 at 11:23 PM ying.huang@intel.com > wrote: > > > > > > > > Can you point me to the regression report? I would like to take a look, > > > thanks. > > > > https://lore.kernel.org/all/1425108604.10337.84.camel@linux.intel.com/ > > Hmm. > > That explanation looks believable, except that our qspinlocks > shouldn't be spinning on the lock itself, but spinning on the mcs node > it inserts into the lock. The referenced regression report is very old (in Feb 2015 for 3.16- 3.17). The ticket spinlock was still used at that time. I believe that things become much better after we used qspinlock. We can test that. Best Regards, Huang, Ying