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 74D88C52D71 for ; Thu, 8 Aug 2024 18:55:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EAC446B007B; Thu, 8 Aug 2024 14:55:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E5CA66B009F; Thu, 8 Aug 2024 14:55:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D25886B00A0; Thu, 8 Aug 2024 14:55:33 -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 B049C6B007B for ; Thu, 8 Aug 2024 14:55:33 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 5DF761415B1 for ; Thu, 8 Aug 2024 18:55:33 +0000 (UTC) X-FDA: 82429981746.21.E9D160C Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.10]) by imf05.hostedemail.com (Postfix) with ESMTP id 154EE10000D for ; Thu, 8 Aug 2024 18:55:29 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="Gk/Ekc3R"; spf=pass (imf05.hostedemail.com: domain of alison.schofield@intel.com designates 192.198.163.10 as permitted sender) smtp.mailfrom=alison.schofield@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723143265; 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=Y3FVUyrH7wmlxCtC4/FdpuP2q93UoJyirgYrU6IMxQs=; b=5QZV9EMFbxk5GML4nkILJYssNUUXOJ/oIPURqRYXbEq9Imlp5pI8Q3fFaHbCBwbS3ctzJj ZOWWdIBikc9Bl5ABWsESJ4PTF+tCOvTHYWUllwax/lVv3EoT7O4R9+NfDA9Fz+SfxPROUq AuuhDFi31zFNYKwF7Yf+AHLMSkM2Teg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723143265; a=rsa-sha256; cv=none; b=w0UNOPun8bf86UlOEjWc2ewZsM3+DP8wrQk5GZyxNAnKhhhOAttzcUpWr0U9bNLgKYc0W/ 3SgLCWkgG7h7QGVJkdPOv8ZPocE9WeB1Po+2PhJR/n9jHjIjrpVZegTgFqlnQMmswYrt1R zzR1qS26mi1e2Qd+Uyc8I0wLeVfacCY= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="Gk/Ekc3R"; spf=pass (imf05.hostedemail.com: domain of alison.schofield@intel.com designates 192.198.163.10 as permitted sender) smtp.mailfrom=alison.schofield@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1723143330; x=1754679330; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=G32pgusq1KzhckqZqehp2esIUUvD3rdQptDyWQ9E8ms=; b=Gk/Ekc3RU2L9UPLraCl8EzQWo4exI1xfQvEdAaoFnhm2I/qzsw/M0yed Oz9wekwqLNiIwNzww2xKEVajY6+3xnGFmQU+8k2OpQI9IcloYq+RIE0T1 Z6vQ0GgP7Za395KJ+v9pJsP0JR5Is7I/wfdyeDLiy6vBiw63vxOoW3Dbj 9e5e/zFj+VMASCKK81Ae6G0FP03YP1kFQ3toZpHHjQ0HdugGYNX3NBn3R 4JQOEBdnK3Yqa57ZFlMKWHGMiE7PB/4VcNehzUc9AkuNqkcRNmRDo99Mi wmoiA+Io6uk8kwoKaKXE7bz1tR969Yhwsz7H4rp1/P9LcmooIkcnz/M8C w==; X-CSE-ConnectionGUID: xDG7Y9XsQ8SWS+NjDIAVqA== X-CSE-MsgGUID: 6oSRNOhqRqOZi9k74a1spg== X-IronPort-AV: E=McAfee;i="6700,10204,11158"; a="32699446" X-IronPort-AV: E=Sophos;i="6.09,273,1716274800"; d="scan'208";a="32699446" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by fmvoesa104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Aug 2024 11:55:28 -0700 X-CSE-ConnectionGUID: sGyYPv3aTLaRDrK47+3Owg== X-CSE-MsgGUID: 989w6FVzSNG3acFu9LuX4w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.09,273,1716274800"; d="scan'208";a="94850394" Received: from aschofie-mobl2.amr.corp.intel.com (HELO aschofie-mobl2) ([10.209.12.215]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Aug 2024 11:55:28 -0700 Date: Thu, 8 Aug 2024 11:55:26 -0700 From: Alison Schofield To: Pasha Tatashin Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-cxl@vger.kernel.org, cerasuolodomenico@gmail.com, hannes@cmpxchg.org, j.granados@samsung.com, lizhijian@fujitsu.com, muchun.song@linux.dev, nphamcs@gmail.com, rientjes@google.com, rppt@kernel.org, souravpanda@google.com, vbabka@suse.cz, willy@infradead.org, dan.j.williams@intel.com, yi.zhang@redhat.com, david@redhat.com, yosryahmed@google.com Subject: Re: [PATCH v3 4/4] mm: don't account memmap per-node Message-ID: References: <20240808154237.220029-1-pasha.tatashin@soleen.com> <20240808154237.220029-5-pasha.tatashin@soleen.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240808154237.220029-5-pasha.tatashin@soleen.com> X-Stat-Signature: d3h6xi4hpmk1pgo3bb7m9eaz8ba1k9t3 X-Rspamd-Queue-Id: 154EE10000D X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1723143329-591660 X-HE-Meta: U2FsdGVkX1/1unB4bomRxd6pG9/lMz7uNkD25bt2e4ZC2AGUdGv3GhT97tcnO/4zKVK+GYULAS0rN7VGTcMMb0WWHknhkBs8LGC9dq3AijDR8ENfKWnmad6bU0iwd7LnRDxY1DAjCYIpIJGZUY4kzHSrtPUWEOF7eHSXQuu8iP4+UDoEhFxRweQTXEgVYg+PzB2DEcKNCaS0Hq1v+jf2wbP/+1LXdr4gJzuig8KRn9X47K3hrxUXe68c1L83z7yc0zY2I90KzY4nAguijQWxPeHrcrd06fLCEbG+BjFI8aMBdO0UGvKAJEMFsEvYZfCZWa8gdh9jNU6e7v7Mr8jWPVhjIfF7KkYqLkXIRSf56W5HPGXaSu6qvOs6NsDPp/YsfBXgUFKYlFMXEC2I3Ius/8JZSG60KVQnLrqPKdwfqpY3xLpHy5hXS+k0qdjzIY/EQ8YuWd6XfLZ8bUMYeM5JcGqmqIEpmpJQ1D43gvdjYMWSoHJYCTNw6b3wLorM1RFQuF+Paq5u3VISSrLJUYSBkhunxNXoLLkHk1ciP7zzXlNXuGO91e7QfwWUK/mUA5FVP8bPLX9adZDCpEOClvDdn7POpkLFu1Uml/t8ovFfKe64iM7uUgJyd2HKqtMv5VJbSmIvYQwJI/R0oKGxz4BZSo2fRysjH4yuRzpYR3EShCZoxegpFhoAZjMCD+6JeSZAErJuWQmNavx5d+/our9jXL0sPPyEck6N80UVNAOb7XuhLm00leE767BAgAehBb9bgkL5R7LLHxhh1cU5E/iJntDkQq8g1fS/USOUZd4Was5UNdWx2UjFv+fM7vusnvstOBl/G7HMFmIb9CUbfRgyiJuyKeo1WgBiuKkJH/1qHk1vjEhGn8fwekWE14P7RJkrbiA8LZ5XC9KHwXQXQRhgoDccv8v/f1KubnLPSd3g2rXK0qyMMW8Bt+cpNKxusX/Qtl05XQ6Jg8i37HfPTCd I1bNrnjP immD+szOuYsRTBzijnE8EJX4GJRVPC9hOrGg+dqILR+38JsMIXNOnLKQ/HYc5HCGu9XIo2l93ny2EUnW6kD74n9m4Jw29onSJCO4wgts7xWnxonvx0H94PYgVoty8opKYU0lB51e7m7OL8IJib+zfsNnnCY5Wg4hEGSBg1reNxQfP/jcT1JESKazgRksGit2j0hBxUb1Wm8dk91zimcsYwHpnKO2mwqdH5pAyAswbpauTGPHPLQgANIse9IcDq6p7hqp0LM8/8vxSBIB85TpNMr7K8jov1WQLquivk1ALVGgnGYpoJSJT/ZX+0DbwfjQadpcmPiznBG1bPGze+HHBodIMWcsw3+jfT721Ylll8Jo0z8w= 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: List-Subscribe: List-Unsubscribe: On Thu, Aug 08, 2024 at 03:42:37PM +0000, Pasha Tatashin wrote: > Currently, when memory is hot-plugged or hot-removed the accounting is > done based on the assumption that memmap is allocated from the same node > as the hot-plugged/hot-removed memory, which is not always the case. > > In addition, there are challenges with keeping the node id of the memory > that is being remove to the time when memmap accounting is actually > performed: since this is done after remove_pfn_range_from_zone(), and > also after remove_memory_block_devices(). Meaning that we cannot use > pgdat nor walking though memblocks to get the nid. > How about directly include the failing cases and user visible impacts as reported in the Tags appended below. --Alison > Given all of that, account the memmap overhead system wide instead. > > For this we are going to be using global atomic counters, but given that > memmap size is rarely modified, and normally is only modified either > during early boot when there is only one CPU, or under a hotplug global > mutex lock, therefore there is no need for per-cpu optimizations. > > Reported-by: Yi Zhang > Closes: https://lore.kernel.org/linux-cxl/CAHj4cs9Ax1=CoJkgBGP_+sNu6-6=6v=_L-ZBZY0bVLD3wUWZQg@mail.gmail.com > Reported-by: Alison Schofield > Closes: https://lore.kernel.org/linux-mm/Zq0tPd2h6alFz8XF@aschofie-mobl2/#t > > Fixes: 15995a352474 ("mm: report per-page metadata information") > Signed-off-by: Pasha Tatashin > --- snip >