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 EACE2C001DB for ; Mon, 14 Aug 2023 06:06:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E604C8D0002; Mon, 14 Aug 2023 02:06:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E0F848D0001; Mon, 14 Aug 2023 02:06:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CD6FB8D0002; Mon, 14 Aug 2023 02:06:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id BAA388D0001 for ; Mon, 14 Aug 2023 02:06:18 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 80DEF1606A3 for ; Mon, 14 Aug 2023 06:06:18 +0000 (UTC) X-FDA: 81121675236.09.2850EDA Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.43]) by imf09.hostedemail.com (Postfix) with ESMTP id 2AF45140008 for ; Mon, 14 Aug 2023 06:06:14 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=SO6H5Cwo; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf09.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.43 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=1691993176; 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=5nAt4s5++9geJV4e8eesm3/O1yv/MDUWo+DaiGBBDyg=; b=izsKE9heZnLdUc0I3HbcF7fLlhpEcC+vfsMyUeQdfgdVFBx+Sae9G/jrf72yR6tqlOiwwM QjRcGyIubR67/k2sIxJe8R66mmn7fwFiDtkbAuxZAA1XLV2oOo8sLFHWgMhGocdqzjHM5w rs+b7PKFxFRIMu4Azr0Xm0bwL1IBwDk= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=SO6H5Cwo; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf09.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.43 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691993176; a=rsa-sha256; cv=none; b=K+7N1jj1/kqJ0RGFOPnyDUvrNX7GuklvfKa4TxnwVp64IOJ2kQqfnAHZ9MYJ+eBqd7z+8S igIEtpAhjBPE8w9RrDHfDdNyFLWTUGVY5EKJ0CfkZ9yI+BY5eTdiUVsBJtja+Ci7ZfCENG Cb9PvV/hIxqQrpnxK4yq1TDONy1xqr8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1691993175; x=1723529175; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=igwqY+DlLN1XbqdBe2kVLRnBm1tJGTmIQMvEm+2XvxA=; b=SO6H5CwoAgWe2v7KhjuLDCfTSdTZiaC7jWoCpMgZgJ0ewYjEB6tt0+wO Q8e6MsaVx4wc7IjA95BZnK9Um868TEFgcgZK+Rc3hvufl/ZYqz35WdKgY Dd7rg78HnGbFCoyvp1mUx35hCqdGZGTQMUCg3cmVauwP9pwe/oNfqv+ia io/vFdrQbt22/4HYnU5Sy3BuXSnKpSvzwgmUTvkMzm7nrvqWldzXlqdoG jLKjhjR9A+XWU9M/MzvyznmFocTiRQsv2LjRuvHYrbCv6HOKhpBP5IbuC 7C6IRKViKZRlsI0XptOhaJqRDlUEPcdJo2s3UsGi5T5eiHDlNzWYczHF1 g==; X-IronPort-AV: E=McAfee;i="6600,9927,10801"; a="458333710" X-IronPort-AV: E=Sophos;i="6.01,171,1684825200"; d="scan'208";a="458333710" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Aug 2023 23:06:12 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10801"; a="710214230" X-IronPort-AV: E=Sophos;i="6.01,171,1684825200"; d="scan'208";a="710214230" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Aug 2023 23:06:09 -0700 From: "Huang, Ying" To: "Verma, Vishal L" Cc: "aneesh.kumar@linux.ibm.com" , "david@redhat.com" , "Jiang, Dave" , "linux-mm@kvack.org" , "osalvador@suse.de" , "akpm@linux-foundation.org" , "linux-kernel@vger.kernel.org" , "Williams, Dan J" , "dave.hansen@linux.intel.com" , "Jonathan.Cameron@Huawei.com" , "nvdimm@lists.linux.dev" , "jmoyer@redhat.com" , "linux-cxl@vger.kernel.org" Subject: Re: [PATCH v2 2/3] mm/memory_hotplug: split memmap_on_memory requests across memblocks References: <20230720-vv-kmem_memmap-v2-0-88bdaab34993@intel.com> <20230720-vv-kmem_memmap-v2-2-88bdaab34993@intel.com> <87a5vmadcw.fsf@linux.ibm.com> <87351e2e43.fsf@yhuang6-desk2.ccr.corp.intel.com> Date: Mon, 14 Aug 2023 14:04:31 +0800 In-Reply-To: (Vishal L. Verma's message of "Wed, 2 Aug 2023 14:02:12 +0800") Message-ID: <87o7ja9n2o.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-Queue-Id: 2AF45140008 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: mdchdkdak6k4h3dz3n33jfmkwqy7d56j X-HE-Tag: 1691993174-184790 X-HE-Meta: U2FsdGVkX19CknCIQOwKdqAGabXMylqXQ4tYyReSYHBieEmQJTM/HYo5LTDQNmSX9rgvrA9BIdX6hi1CBnug9Mp67lttONT3UyVNyDIVcQfr5F9t1mdNHtvCPaFTxv53161NosIwG/ydqv0snw5dQZU+wbORG5JWoMhfb3KbxxzL3G7vQBRtBffY7jGwVymabQh/fOavNGYyykaLfQppRRdDoorxyhQBTw660GOuF2PRX4VeqgWSx8wHLqpDdM5x7uUGILEfAEXPF9VcXT900TWFFEQUqvfalMmZjG6K/AqrX90Km41nTN5vqr7ZIkFsCX9UtOQGNOMZNBUDFef11/UzDCWA0afismRpHDCjTL/QyoHNKN8uqn6mmBu6jbiUxJKygWj3btxHvL6MrZXNGk/tY467sRBPYXnDhYoRmtLp1jMWh9DpJxCcG/Qzt3GNmN/Gw+hJGw8HYDaLqSI/xK8DKAMGeEOhN9x86FjkWvKLTBgw1rEhHhZ6hX+g2ln68wIDU2qgvBwnX+Y9jPP4/5Y3xA+pKXXi9BoRnE6VYm8KLzVblXU3Vv6jOKmrJobbRl5wVMJWAFhI/ED0S0mdrhNFh34j+FexQcH7wpYlh6NRKU2iEfTkHMhd0l7jmaHpn/GmplZCVrJfmSzIovW8i0fxMfjbVf3NmPID00Bx9ICmQsgn3zrKF8qppx7tMYIQB7aYqXYuKHL7YCbLsrEugPHmB/BAX6P3otpl8OkgQOeEvlYd5FxwMI9r2xACdfh7uj30GInpmJfEVRo1QEd3NlIBZlBcaeCjnELgIdb0Jb6O3H3Xm5Of+w3AYqW1+FbedS23W5pDhBFClG+XcbMb+RaNYzVNCBNRjoyFKb3uFF/GT2rsLOcmucpvxUKqHePV87/tCvcBNJR21t1ydJi4yXqvK/Qsfl+VqgtSKgsj8bTnrAGXJ4KM9SQtbWVFMB6uSluCvtvzbIxHZ3WQbdZ J5ZEx6KN 5sYIEj2X+sjrrqHBU5hIeJ5cOFv0RBgT/NkfCADoNNKE6KphlRvSa4oRJBlGx5BoLON1+8EVrTKQ9FNSN93+EKZO0nUrK9qZLiMDeo60dj61tK8WVu5IFPVcIIqESqCeWPL7eJnH/hlYvz7SLs7IHW7uuGrLLapd1v9e1/KoZrhAwgiHiwKU43VBBGO2qzPsc9GkZUI//SnTyBcnFvNxMmcZ4bRxI+FOfekZF8M5T1QTuaZrvgf3QXBYb91LOxqItxnWuGXoNlj/XyHSf0iz5tnZFBw== 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: "Verma, Vishal L" writes: > On Mon, 2023-07-24 at 11:16 +0800, Huang, Ying wrote: >> "Aneesh Kumar K.V" writes: >> > >> > > @@ -1339,27 +1367,20 @@ int __ref add_memory_resource(int nid, >> > > struct resource *res, mhp_t mhp_flags) >> > > /* >> > > * Self hosted memmap array >> > > */ >> > > - if (mhp_flags & MHP_MEMMAP_ON_MEMORY) { >> > > - if (!mhp_supports_memmap_on_memory(size)) { >> > > - ret = -EINVAL; >> > > + if ((mhp_flags & MHP_MEMMAP_ON_MEMORY) && >> > > + mhp_supports_memmap_on_memory(memblock_size)) { >> > > + for (cur_start = start; cur_start < start + size; >> > > + cur_start += memblock_size) { >> > > + ret = add_memory_create_devices(nid, >> > > group, cur_start, >> > > + memblock_ >> > > size, >> > > + mhp_flags >> > > ); >> > > + if (ret) >> > > + goto error; >> > > + } >> > >> > We should handle the below error details here. >> > >> > 1) If we hit an error after some blocks got added, should we >> > iterate over rest of the dev_dax->nr_range. >> > 2) With some blocks added if we return a failure here, we remove >> > the >> > resource in dax_kmem. Is that ok? >> > >> > IMHO error handling with partial creation of memory blocks in a >> > resource range should be >> > documented with this change. >> >> Or, should we remove all added memory blocks upon error? >> > I didn't address these in v3 - I wasn't sure how we'd proceed here. > Something obviously went very wrong and I'd imagine it is okay if this > memory is unusable as a result. > > What woyuld removing the blocks we added look like? Just call > try_remove_memory() from the error path in add_memory_resource()? (for > a range of [start, cur_start) ? I guess that we can just keep the original behavior. Originally, if something goes wrong, arch_remove_memory() and remove_memory_block() (in create_memory_block_devices()) will be called for all added memory range. So, we should do that too? -- Best Regards, Huang, Ying