[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v8 5/6] xen/x86: move NUMA process nodes nodes code from x86 to common


  • To: Wei Chen <Wei.Chen@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 18 Nov 2022 08:43:03 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=MZrinOzMZNiUyNurxX6HSXi6VoMFVYsjaHSFMxw1KPs=; b=BOkHjbxgCaKskkpndPgNZSC/qPYiNZrRHTkVHjPphYBXg4mJ9SCMmKZiLdsN5oi8jRvxLIVOonlnW3Zc8rLWrap8Hy+auJdPYeHVo9nhaaospqvEOmN2I0lIz4V8nFXwChVIzXCys3v0+DOQ5qizPKea9+2gLUbY7ggw1vuTiY3+Qf5nh83yZjaUVeO6Cc7vsKvzCw8zEueA8ESE9qWAXm4jGPXbDwOQxR/MeYt1Ou2oYof4rd3EMf1HlKoPj/PxKP5pMNl8Rdy7RFBhA+M42MrvXZaXd81ZhhDxFXoO0nsjIChPjk6VtzZY47JZyzB9QAHOgTec/ZFpi/B8s3uQ2Q==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q6MpMPRRhRaTbbbKypSNQJ9JFAyHp13gk9MCpGwfGHN8LYk+4f5F4tuJ9W0jnNnut8prSRi/2lYsGGbjpG8lzlXCyw2wLfReRnM1f4j8MPEEUXRuwhMukN9ldKC+KmmvwNuhLNJ5ZjHLSONBAWmqgmZOIdIG2JMUjNjHTMQe9hem1rdQ0r8uPNizFr0U3yBu+/HIkA7U46ckK57x5u4KVg5QjjM7bR4T7eBIBaNe10onxCmiWg8DUgW0FRZmjkB/XVjwvGAZXvk81Jz1gRbaCtzbT6aIDqNOmFy4/+KHXsVUKhFqdsQgZzjgkD4doslH5tCuvydIxAPReQawOHDDLQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: nd <nd@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 18 Nov 2022 07:43:11 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 18.11.2022 08:23, Wei Chen wrote:
>>> -static int __init nodes_cover_memory(void)
>>> -{
>>> -   unsigned int i;
>>> -
>>> -   for (i = 0; ; i++) {
>>> -                           }
>>> -           } while (found && start < end);
>>> -
>>> -           if (start < end) {
>>> -                   printk(KERN_ERR "NUMA: No NODE for RAM range: "
>>> -                           "[%"PRIpaddr", %"PRIpaddr"]\n", start, end - 1);
>>> -                   return 0;
>>> -           }
>>> -   }
>>> -   return 1;
>>> +   numa_fw_nid_name = "PXM";
>>
>> I guess this can't go without a comment, now that we have ...
>>
> 
> Ok, how about following comment:
>       /*
>        * In an extremely unlikely case, srat_parse_regions might not
>        * be called. So set "PXM" before the first caller to use it to
>        * make it more safe.
>        */

Largely okay, but "first caller" looks wrong here (without further
attribution I would read it as meaning "caller of the function we're
in", which makes no sense). Hence I'd make the 2nd sentence just "So
set the variable here just in case."

> And ...
> 
>>> +   if (!numa_update_node_memblks(node, pxm, ma->base_address, ma-
>>> length,
>>> +                                 ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE))
>>> +           numa_fw_bad();
>>>  }
>>>
>>>  void __init acpi_numa_arch_fixup(void) {}
>>> @@ -534,6 +295,7 @@ void __init srat_parse_regions(paddr_t addr)
>>>         acpi_table_parse(ACPI_SIG_SRAT, acpi_parse_srat))
>>>             return;
>>>
>>> +   numa_fw_nid_name = "PXM";
>>
>> ... this as well. Otherwise someone may spot the redundancy and either
>> propose to drop one, or it'll take them quite a bit of time to figure
>> why both are there. I thought this would go without saying, so I'm
>> sorry for not making this explicit earlier on.
> 
> ...
>       /* Set "PXM" as earlier as we can for those functions will use it. */
>>> +   numa_fw_nid_name = "PXM";

Just 'Set "PXM" as early as feasible'? ("can" would be wrong, because in
principle we could of course set it earlier. Yet we want to keep the
setting within the present flow of setup, and without introducing a
layering violation.)

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.