Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 14 Jun 2023 05:44:19 -0700
From:   Dan Williams <dan.j.williams@intel.com>
To:     <alison.schofield@intel.com>,
        "Rafael J. Wysocki" <rafael@kernel.org>,
        "Len Brown" <lenb@kernel.org>,
        Dan Williams <dan.j.williams@intel.com>,
        "Thomas Gleixner" <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>,
        "Borislav Petkov" <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        "H. Peter Anvin" <hpa@zytor.com>,
        Andy Lutomirski <luto@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        "Jonathan Cameron" <Jonathan.Cameron@huawei.com>,
        Dave Jiang <dave.jiang@intel.com>,
        Mike Rapoport <rppt@kernel.org>
CC:     Alison Schofield <alison.schofield@intel.com>, <x86@kernel.org>,
        <linux-cxl@vger.kernel.org>, <linux-acpi@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>,
        Derick Marks <derick.w.marks@intel.com>
Subject: RE: [PATCH v2 1/2] x86/numa: Introduce numa_fill_memblks()
Message-ID: <6489b6234a03e_142af829454@dwillia2-xfh.jf.intel.com.notmuch>
References: <cover.1686712819.git.alison.schofield@intel.com>
 <9fcc548a6b4727cb2538e5227d7bad2e94e6adaf.1686712819.git.alison.schofield@intel.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <9fcc548a6b4727cb2538e5227d7bad2e94e6adaf.1686712819.git.alison.schofield@intel.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?E9ab+npXfOlkkpmdbnQ/51CiVSKW1BSIcG658jr+PvUtgura9vURLgRFQgZ/?=
 =?us-ascii?Q?pdGA9Mobkr89OVr9cfmqxb95w5m5X7ZD1e6cbm2n5S8ZDvk6ZSRV7lk0Loxq?=
 =?us-ascii?Q?HtyM4AzfjKjowFXVddyvocXHpr6oVXsPQ9uzgNi2D7s0wq+B/kW+FWRmKe0E?=
 =?us-ascii?Q?AZKppiCudqPfopEoa8UjhEC0FN49wSUPCedTMrkQYnK+pnc1la4yNt5gamYD?=
 =?us-ascii?Q?JSdw1qJJygbp1e4Qvqaj8YQEa2oYx41Gwyn1pGmnH+jEnERFzSTJ8Pfagy6N?=
 =?us-ascii?Q?E15QYCBpxIUAGwASg/+L9CIJVBo1XZs21wa6+H+fVmwJ6Me59jg2aOqIW4nv?=
 =?us-ascii?Q?bbDZ/3lvqwlvQveNJiNdCtW2cFWr5X53MR6J+RFwEKmbIKG6HAWZlBAeDLis?=
 =?us-ascii?Q?ib5gifpoTJSwN0Wv98tjqhSSJImSh9VGjayddgX27bRdWoKwgSctlxcOnRnR?=
 =?us-ascii?Q?LqGkNMvXqhZkAsKo/mPfFg1Sc3U7LlI30hWA3rr2sZha/+6rKJbx0PYIdeDh?=
 =?us-ascii?Q?WaVP/6/i2P9G368gRYZBCNc7CXwWflbRVyg09C8tO2zpvBSJopbjMDc1WDjR?=
 =?us-ascii?Q?1liVJGQDTRwg7CKChHiwv1i5W6AF2af/ea3rosmDvPN5U3G3AcTorxIIS0bk?=
 =?us-ascii?Q?4YPLijVFXDMEAl0ai9LSdT7/2Pyq5xlt+yHxll2AYXu872ICXsVYUL3zMUPX?=
 =?us-ascii?Q?/Zfkmd7S2bfX70B84TCoJ3AkHDGwpCtzMb4VwguyM8S+L+mRRoTf/uMhsjVb?=
 =?us-ascii?Q?Gh5x/gtIAU2ndj6VTV1rmpectDbbbA4VnQhDwvrJ4s0FDWLZDOzo296Lu2fC?=
 =?us-ascii?Q?TJsfmw87GOqf05Z40izsjDsYNT55bWgcUOteVtJ50wdHRFahyHQ6yuHWJ3M3?=
 =?us-ascii?Q?vJ+cdY6t64NkiNjFK7EcYaGoniAMi7o2euiT1dH1fKSW6KvKHNUISU1/fE0I?=
 =?us-ascii?Q?llRBcePdYma45SnjuwsJwpAz5jtuHp18Q1hT1mJHBJNtRFzZn+Gp3wRuWyDt?=
 =?us-ascii?Q?s0JPnRvIxp3RaBk38cy6WUKlsoA1zhFvVVVSPxnypu4qButh6VF3AOXMEOnQ?=
 =?us-ascii?Q?lH4/grYxF+iJroBXGdEEsyP6qTTUCcL+b7opbHkYaxVOaPLVgM+3vhS7xYwP?=
 =?us-ascii?Q?VvxFE21GV3DbyuVp0qtpwHRkVS5yrtPNd5IzKPi7c6QyBxwqEpIV6CIXAquv?=
 =?us-ascii?Q?CpJExASSGSMxEmhmVL4TKbq+2rUssxCVZ2O5JDcUt3ZHA29C+V9KOnC93WSt?=
 =?us-ascii?Q?iT+04glKQ7+gi6JBsXuvgxs3kb8plV8ao/EJygim5oeAKPu8xohOyUQETOYU?=
 =?us-ascii?Q?iY3SBh/NbFSHtlH9/2Y1TtWDIPxTLDlJOnAtoQAOBwoRLMF/j3KM9+AkS4OA?=
 =?us-ascii?Q?jtrqeoiIAlR3DnYiqisjoYpkmn69tCVVW3CjCssLIarYDTAnNMq881POjCkP?=
 =?us-ascii?Q?gZlypI2tiklbRs12chxlYfSuIpwx2UJQ9UKSobBa8JUWWP6jZEKngnH5ELA1?=
 =?us-ascii?Q?v1R+E4uGew2X7bZUm+hhRKPM9/d8qRAfA3/MgmpDeMS9oIjSo4/xl3WckNLN?=
 =?us-ascii?Q?Ma2nt9+tWK8uekLFc5gVm0DfQ4KkDaj1/SjXkJx2q5K2EXZWTbohMJZoBd7Q?=
 =?us-ascii?Q?fg=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 70388179-afa4-415a-e8eb-08db6cd513da
X-MS-Exchange-CrossTenant-AuthSource: PH8PR11MB8107.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jun 2023 12:44:22.1551
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: O9yGhtiKxKRSv6u2pTmOmfe9SLp06g64C7Yp3IOEJ81X3LOQSKAOMmpNeRWg0ZF8nqnCKD48ofth3J9hRu6ru+2RjL27LzViO8H+xmyG+s4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB7711
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

alison.schofield@ wrote:
> From: Alison Schofield <alison.schofield@intel.com>
> 
> numa_fill_memblks() fills in the gaps in numa_meminfo memblks
> over an HPA address range.
> 
> The ACPI driver will use numa_fill_memblks() to implement a new Linux
> policy that prescribes extending proximity domains in a portion of a
> CFMWS window to the entire window.
> 
> Dan Williams offered this explanation of the policy:
> A CFWMS is an ACPI data structure that indicates *potential* locations
> where CXL memory can be placed. It is the playground where the CXL
> driver has free reign to establish regions. That space can be populated
> by BIOS created regions, or driver created regions, after hotplug or
> other reconfiguration.
> 
> When BIOS creates a region in a CXL Window it additionally describes
> that subset of the Window range in the other typical ACPI tables SRAT,
> SLIT, and HMAT. The rationale for BIOS not pre-describing the entire
> CXL Window in SRAT, SLIT, and HMAT is that it can not predict the
> future. I.e. there is nothing stopping higher or lower performance
> devices being placed in the same Window. Compare that to ACPI memory
> hotplug that just onlines additional capacity in the proximity domain
> with little freedom for dynamic performance differentiation.
> 
> That leaves the OS with a choice, should unpopulated window capacity
> match the proximity domain of an existing region, or should it allocate
> a new one? This patch takes the simple position of minimizing proximity
> domain proliferation by reusing any proximity domain intersection for
> the entire Window. If the Window has no intersections then allocate a
> new proximity domain. Note that SRAT, SLIT and HMAT information can be
> enumerated dynamically in a standard way from device provided data.
> Think of CXL as the end of ACPI needing to describe memory attributes,
> CXL offers a standard discovery model for performance attributes, but
> Linux still needs to interoperate with the old regime.
> 
> Reported-by: Derick Marks <derick.w.marks@intel.com>
> Suggested-by: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Alison Schofield <alison.schofield@intel.com>
> Tested-by: Derick Marks <derick.w.marks@intel.com>
[..]
> diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
> index 2aadb2019b4f..fa82141d1a04 100644
> --- a/arch/x86/mm/numa.c
> +++ b/arch/x86/mm/numa.c
[..]
> @@ -961,4 +962,90 @@ int memory_add_physaddr_to_nid(u64 start)
>  	return nid;
>  }
>  EXPORT_SYMBOL_GPL(memory_add_physaddr_to_nid);
> +
> +static int __init cmp_memblk(const void *a, const void *b)
> +{
> +	const struct numa_memblk *ma = *(const struct numa_memblk **)a;
> +	const struct numa_memblk *mb = *(const struct numa_memblk **)b;
> +
> +	if (ma->start != mb->start)
> +		return (ma->start < mb->start) ? -1 : 1;
> +
> +	/* Caller handles duplicate start addresses */
> +	return 0;

This can be simplified to:

static int __init cmp_memblk(const void *a, const void *b)
{
	const struct numa_memblk *ma = *(const struct numa_memblk **)a;
	const struct numa_memblk *mb = *(const struct numa_memblk **)b;

	return ma->start - mb->start;
}

> +}
> +
> +static struct numa_memblk *numa_memblk_list[NR_NODE_MEMBLKS] __initdata;
> +
> +/**
> + * numa_fill_memblks - Fill gaps in numa_meminfo memblks
> + * @start: address to begin fill
> + * @end: address to end fill
> + *
> + * Find and extend numa_meminfo memblks to cover the @start-@end
> + * HPA address range, such that the first memblk includes @start,
> + * the last memblk includes @end, and any gaps in between are
> + * filled.
> + *
> + * RETURNS:
> + * 0		  : Success
> + * NUMA_NO_MEMBLK : No memblk exists in @start-@end range
> + */
> +
> +int __init numa_fill_memblks(u64 start, u64 end)
> +{
> +	struct numa_memblk **blk = &numa_memblk_list[0];
> +	struct numa_meminfo *mi = &numa_meminfo;
> +	int count = 0;
> +	u64 prev_end;
> +
> +	/*
> +	 * Create a list of pointers to numa_meminfo memblks that
> +	 * overlap start, end. Exclude (start == bi->end) since
> +	 * end addresses in both a CFMWS range and a memblk range
> +	 * are exclusive.
> +	 *
> +	 * This list of pointers is used to make in-place changes
> +	 * that fill out the numa_meminfo memblks.
> +	 */

Thanks for this comment, looks good.

> +	for (int i = 0; i < mi->nr_blks; i++) {
> +		struct numa_memblk *bi = &mi->blk[i];
> +
> +		if (start < bi->end && end >= bi->start) {
> +			blk[count] = &mi->blk[i];
> +			count++;
> +		}
> +	}
> +	if (!count)
> +		return NUMA_NO_MEMBLK;
> +
> +	/* Sort the list of pointers in memblk->start order */
> +	sort(&blk[0], count, sizeof(blk[0]), cmp_memblk, NULL);
> +
> +	/* Make sure the first/last memblks include start/end */
> +	blk[0]->start = min(blk[0]->start, start);
> +	blk[count - 1]->end = max(blk[count - 1]->end, end);
> +
> +	/*
> +	 * Fill any gaps by tracking the previous memblks end address,
> +	 * prev_end, and backfilling to it if needed. Avoid filling
> +	 * overlapping memblks by making prev_end monotonically non-
> +	 * decreasing.

I am not immediately understanding the use of the term monotonically
non-decreasing here? I think the first sentence of this comment is
enough, or am I missing a nuance?

> +	 */
> +	prev_end = blk[0]->end;
> +	for (int i = 1; i < count; i++) {
> +		struct numa_memblk *curr = blk[i];
> +
> +		if (prev_end >= curr->start) {
> +			if (prev_end < curr->end)
> +				prev_end = curr->end;
> +		} else {
> +			curr->start = prev_end;
> +			prev_end = curr->end;
> +		}
> +	}
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(numa_fill_memblks);

This export is not needed. The only caller of this is
drivers/acpi/numa/srat.c which is only ever built-in, not a module.