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 0FB59E80A8E for ; Wed, 27 Sep 2023 05:44:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8772B8D0016; Wed, 27 Sep 2023 01:44:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 828988D0002; Wed, 27 Sep 2023 01:44:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7154C8D0016; Wed, 27 Sep 2023 01:44:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 624038D0002 for ; Wed, 27 Sep 2023 01:44:40 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 2CD64160F03 for ; Wed, 27 Sep 2023 05:44:40 +0000 (UTC) X-FDA: 81281287920.12.7FE8AF1 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.120]) by imf27.hostedemail.com (Postfix) with ESMTP id 3351C40008 for ; Wed, 27 Sep 2023 05:44:36 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Jwt24bsJ; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf27.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.120 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695793477; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=jLkgmJJAHvkN8MBTXtIehItnR6471qPRJUAauIsDNCs=; b=eL2OIReKB0jv8V83On1tjKzwvwQKrjRHfTHIXo4yxSHyDnUcVqVm+v9YHXRlCeyaomnqSp Jj/AnraQRIF6q+oAbJY6PC61SlIriakHUGcwNF7wzsI8JMsc/D+zE8YcYEvBXPZTSh97T8 rSaMxqg3eX0SAd5nqTuhoODRDddnnwA= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=Jwt24bsJ; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf27.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.120 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695793477; a=rsa-sha256; cv=none; b=PNiLHU2tm+csp3MAQgXqskmeZM5gWFjZaTdr5iRt/RRh4yE/GahlEQL38HBZIjrZrIXUw6 zTOSIDTy1d08OEk64zUetef+qDHu5T/wi2FX0Siy3HKZtk6zZXFKFh64Axg1qvp9mMODw5 Xadz9zgC9+EsTv3rh0YE6qofCbWfRFc= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695793477; x=1727329477; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=eVHpqGZhAIIy6UMnGBM0tF+7WZo7Dg9HmYYsMtGxPvc=; b=Jwt24bsJbf6ekRyE/H+DrpdoL7roFxOkD5BrVGxTG2e7bKqkWzg7aBaG AUGGG/BpbmsweTbXFP00aAvv6uhQBNojtBfWs5rUPKmZqiFTl+y+LDLHx ATOfYgLH59uOi6dxKQ7QrroLT5nzC+I0F7G11OK4OijLjB1Udi8IJMwmO hcQu0D06I+sSwVNCKYN/3aO6ro0SCks0M6/H41Ux+1xZcuxUTflrMf5CK pCxj3p+HntGYSXXqwPdzqnHGMvp675r5RTmczkKi3Yx5uZif5IEHlzR9Q kNSkXIiT+XQ4yFihUVA0dTHDjXC/eGDcCAd7KCBRFxQ/E2M5GH25RYCQb A==; X-IronPort-AV: E=McAfee;i="6600,9927,10845"; a="380603174" X-IronPort-AV: E=Sophos;i="6.03,179,1694761200"; d="scan'208";a="380603174" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Sep 2023 22:44:35 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10845"; a="892469264" X-IronPort-AV: E=Sophos;i="6.03,179,1694761200"; d="scan'208";a="892469264" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmsmga001-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Sep 2023 22:43:26 -0700 From: "Huang, Ying" To: Johannes Weiner Cc: Andrew Morton , Vlastimil Babka , Mel Gorman , Miaohe Lin , Kefeng Wang , Zi Yan , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/6] mm: page_alloc: remove pcppage migratetype caching References: <20230911195023.247694-1-hannes@cmpxchg.org> <20230911195023.247694-2-hannes@cmpxchg.org> Date: Wed, 27 Sep 2023 13:42:25 +0800 In-Reply-To: <20230911195023.247694-2-hannes@cmpxchg.org> (Johannes Weiner's message of "Mon, 11 Sep 2023 15:41:42 -0400") Message-ID: <87y1gsrx32.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 3351C40008 X-Stat-Signature: 5nucp7cm8d5wtupaqus8xk4y5gbtd6bs X-Rspam-User: X-HE-Tag: 1695793476-441251 X-HE-Meta: U2FsdGVkX1+1eOJ9UMcCkVGloyUqWfDLJTyZWJi49L+fueZJUxLejJs218OK9aySLKHXgXtbZ9O2wTXUVC8s/kDQXV+xjjgFvESNMjJy/qXPlMnf99gpae9wZ/XUiKJaUFefl6v4364NL51up+0zWYXs4Fs9dWhZGSNpHU+4EMxwptEjLKFyy7vur8z8Bj4iXpCIWJokeoKFKQdsESpiXbvwPoUjxQn7/ovOPdYNKwg6+SxocvXOa77aeUEJ1VjTf654j4dJfeAitlktKt12f+QGMI7wjWJyJmwJw4gjdjcR1DT/p8pxKwWFTt21tSJpewNwjTYhlMc60p4fgPE4zeZ0FczAqW8zOs+FxEV2nVJZSOYhLQ/Vz8xbARh3TJOFyhS+cVWE0l+J4VH35/OyLtcHgQK50LsZeIXyRtoqH0KJIlNcSksEWzby8WUSsFt5WLmLvLVWS7M3OPyLbGk4GjbmlN0SbeES5ZYw4RZ3G9NLNIfmgwFNeiMTQ1dGPMo+M1PJa3G3hIIFqq+/aDmeDWXr2ABSBY5SPCxZFxGtNAjnmEc/dbEgo3EqwVkEZmvlsDET2GnFcJqlilau03KKDHXLkKoZe1sYw3ugh6LxJba5lRenDTRxm8VXAQvKngJIkEUz/pSBnl2lwwe8Pi0Ic/W0D3totBPBHlkMRjIjY8oRitjcaJ6fxuJufXuZUdwVJDt6yUY8+Wrfql+QrhzxqOvNB3FdH0HA7I1RyYBDJVfvDOPEgbqHVXoQgGE3VQNhWvMNu4jtPLloEn09fuCIRczX/fPUAwMxlObHKTen5hxLg8obOv9BlbQcso7UIngt6YBIloaN0gVa+McyPz49D9HLH1l4ljKRJGuyNyWsc1SG3Wrzqg49FU+Xl7STw2hq09RbkLQvOpsu+0AwDc/T5CTWjLRnk8FyevDA34yjaJqNYimPViKdJtyQOgZ370SSFSpMC6dYjwFXKBbaFhC qVqI/iN7 pYQwPh1AWaxvY+C3VeDUQzYv1sKh442sTh6SZ5KriWNS5vpsE+Ba4k3V/ySE3cUjR6aR9NDmk4lExFok3BT8zMhRYkJBvS1f/Vm/Xq/wGUmTQyE5ROQOSqmU6bBN0lL82jle1tviIXflT41XClvTwebcfkTHzPC0ndGVUZcyaTswYVfSCV9IJHXh7Ozqjsk2lR/HFEzQO0bdBoh98/CeJSlmr8rjSl3Um0krRqzBZfN5RerlEZiW98j5KubYg4dofUtdI 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: Johannes Weiner writes: > The idea behind the cache is to save get_pageblock_migratetype() > lookups during bulk freeing. A microbenchmark suggests this isn't > helping, though. The pcp migratetype can get stale, which means that > bulk freeing has an extra branch to check if the pageblock was > isolated while on the pcp. > > While the variance overlaps, the cache write and the branch seem to > make this a net negative. The following test allocates and frees > batches of 10,000 pages (~3x the pcp high marks to trigger flushing): > > Before: > 8,668.48 msec task-clock # 99.735 CPUs utilized ( +- 2.90% ) > 19 context-switches # 4.341 /sec ( +- 3.24% ) > 0 cpu-migrations # 0.000 /sec > 17,440 page-faults # 3.984 K/sec ( +- 2.90% ) > 41,758,692,473 cycles # 9.541 GHz ( +- 2.90% ) > 126,201,294,231 instructions # 5.98 insn per cycle ( +- 2.90% ) > 25,348,098,335 branches # 5.791 G/sec ( +- 2.90% ) > 33,436,921 branch-misses # 0.26% of all branches ( +- 2.90% ) > > 0.0869148 +- 0.0000302 seconds time elapsed ( +- 0.03% ) > > After: > 8,444.81 msec task-clock # 99.726 CPUs utilized ( +- 2.90% ) > 22 context-switches # 5.160 /sec ( +- 3.23% ) > 0 cpu-migrations # 0.000 /sec > 17,443 page-faults # 4.091 K/sec ( +- 2.90% ) > 40,616,738,355 cycles # 9.527 GHz ( +- 2.90% ) > 126,383,351,792 instructions # 6.16 insn per cycle ( +- 2.90% ) > 25,224,985,153 branches # 5.917 G/sec ( +- 2.90% ) > 32,236,793 branch-misses # 0.25% of all branches ( +- 2.90% ) > > 0.0846799 +- 0.0000412 seconds time elapsed ( +- 0.05% ) > > A side effect is that this also ensures that pages whose pageblock > gets stolen while on the pcplist end up on the right freelist and we > don't perform potentially type-incompatible buddy merges (or skip > merges when we shouldn't), whis is likely beneficial to long-term > fragmentation management, although the effects would be harder to > measure. Settle for simpler and faster code as justification here. I suspected the PCP allocating/freeing path may be influenced (that is, allocating/freeing batch is less than PCP high). So I tested one-process will-it-scale/page_fault1 with sysctl percpu_pagelist_high_fraction=8. So pages will be allocated/freed from/to PCP only. The test results are as follows, Before: will-it-scale.1.processes 618364.3 (+- 0.075%) perf-profile.children.get_pfnblock_flags_mask 0.13 (+- 9.350%) After: will-it-scale.1.processes 616512.0 (+- 0.057%) perf-profile.children.get_pfnblock_flags_mask 0.41 (+- 22.44%) The change isn't large: -0.3%. Perf profiling shows the cycles% of get_pfnblock_flags_mask() increases. -- Best Regards, Huang, Ying