All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Chen <Wei.Chen@arm.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: nd <nd@arm.com>, "Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>, "Wei Liu" <wl@xen.org>,
	"George Dunlap" <george.dunlap@citrix.com>,
	"Julien Grall" <julien@xen.org>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v5 5/6] xen/x86: move NUMA scan nodes codes from x86 to common
Date: Mon, 10 Oct 2022 15:03:53 +0800	[thread overview]
Message-ID: <e28f8faf-89fe-1e8f-4b8c-77097c2f2a90@arm.com> (raw)
In-Reply-To: <PAXPR08MB7420DE5F342F17E77F5483879E219@PAXPR08MB7420.eurprd08.prod.outlook.com>

Hi Jan,

On 2022/10/9 15:25, Wei Chen wrote:
> Hi Jan,
> >
>>>> Even more so an answer to my question would be nice: You'll then have
>>>> CONFIG_HAS_NUMA_NODE_FWID=y even on Arm (using PXM as mandated by ACPI
>>>> when in ACPI mode). But then what's the FWID for DT? I know it was me
>>>> to suggest this build time distinction, but I'm afraid I wasn't doing
>>>> much good with that (and I'm sorry).
>>>
>>> How about introducing a flag for selected NUMA implementation to
>>> set it in runtime?
>>> For example:
>>> bool numa_has_fw_nodeid;
>>>
>>> ACPI NUMA will set this flag to 1, but 0 for DT NUMA.
>>
>> That's an option alongside going back to what you had in an earlier
>> version. Another would be (name subject to improvement)
>>
>> const char *__ro_after_init numa_fw_nid_name;
>>

When I was dealing with this comment, I found that I was still a little 
unclear:

When we were introducing "CONFIG_HAS_NUMA_NODE_FWID", we wanted to 
eliminate the redundant code of:
if ( fwid_name not equal to "node" )
     printk(KERN_INFO "NUMA: Node %u %s %u [%"PRIpaddr"%"PRIpaddr"]%s\n",
            node, fwid_name , arch_nid, start, end - 1,
            hotplug ? " (hotplug)" : "");
else
     printk(KERN_INFO "NUMA: Node %u [%"PRIpaddr", %"PRIpaddr"]%s\n",
            node, start, end - 1, hotplug ? " (hotplug)" : "");

But when I am working with numa_fw_nid_name, I find it's still not
easy to reduce above redundant code. For example:

"NUMA: Node %u %s %u
When numa_fw_nid_name = NULL, we can print "" for %s, but can't reduce
the second %u.

So can we split this message into 3 lines like:
     printk(KERN_INFO "NUMA: Node %u"...);
     if (numa_fw_nid_name)
         printk(KERN_INFO " %s %u"...);
     printk(KERN_INFO "[%"PRIpaddr"%"PRIpaddr"]%s\n"...);

Or another option, we can force each NUMA implementation to assign a
string for numa_fw_nid_name. For example, in DT NUMA, we can assign
numa_fw_nid_name="SOCKET".

Cheers,
Wei Chen

>> which for ACPI would be set to "PXM" (eliminating the need to pass
>> it to certain functions, albeit the fw_nid will continue to need to
>> be passed anyway). I guess I'm not really certain which of this and
>> your earlier approach I prefer; the boolean you suggest above looks
>> less desirable to me, though.
>>
> 
> Ok, I will follow your suggestion.
> 
> Cheers,
> Wei Chen
> 
>> Jan


  reply	other threads:[~2022-10-10  7:04 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-20  9:12 [PATCH v5 0/6] Device tree based NUMA support for Arm - Part#2 Wei Chen
2022-09-20  9:12 ` [PATCH v5 1/6] xen/x86: Provide helpers for common code to access acpi_numa Wei Chen
2022-09-27  7:37   ` Jan Beulich
2022-09-29  6:29     ` Wei Chen
2022-09-20  9:12 ` [PATCH v5 2/6] xen/x86: move generically usable NUMA code from x86 to common Wei Chen
2022-09-27  8:19   ` Jan Beulich
2022-09-27  9:39     ` Jan Beulich
2022-09-29  7:58       ` Wei Chen
2022-09-29  7:43     ` Wei Chen
2022-09-29 12:14       ` Jan Beulich
2022-09-30  1:45         ` Wei Chen
2022-09-20  9:12 ` [PATCH v5 3/6] xen/x86: Use ASSERT instead of VIRTUAL_BUG_ON for phys_to_nid Wei Chen
2022-09-20  9:12 ` [PATCH v5 4/6] xen/x86: use arch_get_ram_range to get information from E820 map Wei Chen
2022-09-20  9:12 ` [PATCH v5 5/6] xen/x86: move NUMA scan nodes codes from x86 to common Wei Chen
2022-09-27 15:48   ` Jan Beulich
2022-09-29  8:21     ` Wei Chen
2022-09-29 12:21       ` Jan Beulich
2022-09-30  1:40         ` Wei Chen
2022-09-30  6:03           ` Jan Beulich
2022-10-09  7:25             ` Wei Chen
2022-10-10  7:03               ` Wei Chen [this message]
2022-10-10  8:25                 ` Jan Beulich
2022-09-20  9:12 ` [PATCH v5 6/6] xen: introduce a Kconfig option to configure NUMA nodes number Wei Chen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e28f8faf-89fe-1e8f-4b8c-77097c2f2a90@arm.com \
    --to=wei.chen@arm.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=nd@arm.com \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.