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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no 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 9B4F1C432BE for ; Wed, 1 Sep 2021 15:12:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 72AEF6108E for ; Wed, 1 Sep 2021 15:12:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245714AbhIAPNw (ORCPT ); Wed, 1 Sep 2021 11:13:52 -0400 Received: from mga01.intel.com ([192.55.52.88]:50231 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231807AbhIAPNv (ORCPT ); Wed, 1 Sep 2021 11:13:51 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10094"; a="241048314" X-IronPort-AV: E=Sophos;i="5.84,369,1620716400"; d="scan'208";a="241048314" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Sep 2021 08:12:53 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.84,369,1620716400"; d="scan'208";a="541844834" Received: from tassilo.jf.intel.com (HELO tassilo.localdomain) ([10.54.74.11]) by fmsmga002.fm.intel.com with ESMTP; 01 Sep 2021 08:12:25 -0700 Received: by tassilo.localdomain (Postfix, from userid 1000) id 091F8301C52; Wed, 1 Sep 2021 08:12:25 -0700 (PDT) From: Andi Kleen To: Feng Tang Cc: Michal Koutn?? , Johannes Weiner , Linus Torvalds , andi.kleen@intel.com, kernel test robot , Roman Gushchin , Michal Hocko , Shakeel Butt , Balbir Singh , Tejun Heo , Andrew Morton , LKML , lkp@lists.01.org, kernel test robot , "Huang\, Ying" , Zhengjun Xing Subject: Re: [mm] 2d146aa3aa: vm-scalability.throughput -36.4% regression References: <20210812031910.GA63920@shbuild999.sh.intel.com> <20210816032855.GB72770@shbuild999.sh.intel.com> <20210817024500.GC72770@shbuild999.sh.intel.com> <20210817164737.GA23342@blackbody.suse.cz> <20210818023004.GA17956@shbuild999.sh.intel.com> <20210831063036.GA46357@shbuild999.sh.intel.com> <20210831092304.GA17119@blackbody.suse.cz> <20210901045032.GA21937@shbuild999.sh.intel.com> Date: Wed, 01 Sep 2021 08:12:24 -0700 In-Reply-To: <20210901045032.GA21937@shbuild999.sh.intel.com> (Feng Tang's message of "Wed, 1 Sep 2021 12:50:32 +0800") Message-ID: <877dg0wcrr.fsf@linux.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Feng Tang writes: > > Yes, the tests I did is no matter where the 128B padding is added, the > performance can be restored and even improved. I wonder if we can find some cold, rarely accessed, data to put into the padding to not waste it. Perhaps some name strings? Or the destroy support, which doesn't sound like its commonly used. -Andi