|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [PATCH v3 8/9] xen/x86: add detection of memory interleaves for different nodes
Hi Jan,
> -----Original Message-----
> From: Jan Beulich <jbeulich@xxxxxxxx>
> Sent: 2022年5月18日 21:31
> To: Wei Chen <Wei.Chen@xxxxxxx>
> Cc: nd <nd@xxxxxxx>; Andrew Cooper <andrew.cooper3@xxxxxxxxxx>; Roger Pau
> Monné <roger.pau@xxxxxxxxxx>; Wei Liu <wl@xxxxxxx>; Jiamei Xie
> <Jiamei.Xie@xxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [PATCH v3 8/9] xen/x86: add detection of memory interleaves
> for different nodes
>
> On 11.05.2022 03:46, Wei Chen wrote:
> > --- a/xen/arch/x86/srat.c
> > +++ b/xen/arch/x86/srat.c
> > @@ -42,6 +42,12 @@ static struct node node_memblk_range[NR_NODE_MEMBLKS];
> > static nodeid_t memblk_nodeid[NR_NODE_MEMBLKS];
> > static __initdata DECLARE_BITMAP(memblk_hotplug, NR_NODE_MEMBLKS);
> >
> > +enum conflicts {
> > + NO_CONFLICT = 0,
>
> No need for the "= 0".
>
Ack.
> > + ERR_OVERLAP,
>
> While this at least can be an error (the self-overlap case is merely
> warned about), ...
>
> > + ERR_INTERLEAVE,
>
> ... I don't think this is, and hence I'd recommend to drop "ERR_".
>
Oh, yes. I all drop it for all above enumerations.
> > @@ -119,20 +125,43 @@ int valid_numa_range(paddr_t start, paddr_t end,
> nodeid_t node)
> > return 0;
> > }
> >
> > -static __init int conflicting_memblks(paddr_t start, paddr_t end)
> > +static enum conflicts __init
> > +conflicting_memblks(nodeid_t nid, paddr_t start, paddr_t end,
> > + paddr_t nd_start, paddr_t nd_end, int *mblkid)
>
> Why "int"? Can the value passed back be negative?
>
The caller "acpi_numa_memory_affinity_init" defines int for node memory
block id, and as a return value at the same time. So I haven't changed it.
As we don't use this "int" for return value any more, I agree, it will
never be negative, I would fix it.
> > {
> > int i;
> >
> > + /*
> > + * Scan all recorded nodes' memory blocks to check conflicts:
> > + * Overlap or interleave.
> > + */
> > for (i = 0; i < num_node_memblks; i++) {
> > struct node *nd = &node_memblk_range[i];
> > + *mblkid = i;
>
> Style: Please maintain a blank line between declaration(s) and
> statement(s).
>
Ok.
> > @@ -310,42 +342,67 @@ acpi_numa_memory_affinity_init(const struct
> acpi_srat_mem_affinity *ma)
> > bad_srat();
> > return;
> > }
> > +
> > + /*
> > + * For the node that already has some memory blocks, we will
> > + * expand the node memory range temporarily to check memory
> > + * interleaves with other nodes. We will not use this node
> > + * temp memory range to check overlaps, because it will mask
> > + * the overlaps in same node.
> > + *
> > + * Node with 0 bytes memory doesn't need this expandsion.
> > + */
> > + nd_start = start;
> > + nd_end = end;
> > + nd = &nodes[node];
> > + if (nd->start != nd->end) {
> > + if (nd_start > nd->start)
> > + nd_start = nd->start;
> > +
> > + if (nd_end < end)
>
> Did you mean nd->end here on the right side of < ? By intentionally
Oh! thanks for pointing out this one! Yes, right side should be nd->end.
> not adding "default:" in the body, you then also allow the compiler
> to point out that addition of a new enumerator also needs handling
> here.
>
Did you mean, we need to add if ... else ... in this block? If yes,
is it ok to update this block like:
if (nd->start != nd->end) {
nd_start = min(nd_start, nd->start);
nd_end = max(nd_end, nd->end);
}
?
> > + nd_end = nd->end;
> > + }
> > +
> > /* It is fine to add this area to the nodes data it will be used
> later*/
> > - i = conflicting_memblks(start, end);
> > - if (i < 0)
> > - /* everything fine */;
> > - else if (memblk_nodeid[i] == node) {
> > - bool mismatch = !(ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE) !=
> > - !test_bit(i, memblk_hotplug);
> > -
> > - printk("%sSRAT: PXM %u (%"PRIpaddr"-%"PRIpaddr") overlaps with
> itself (%"PRIpaddr"-%"PRIpaddr")\n",
> > - mismatch ? KERN_ERR : KERN_WARNING, pxm, start, end,
> > - node_memblk_range[i].start, node_memblk_range[i].end);
> > - if (mismatch) {
> > + status = conflicting_memblks(node, start, end, nd_start, nd_end, &i);
> > + if (status == ERR_OVERLAP) {
>
> Please use switch(status) when checking enumerated values.
>
Ok, I will do it.
> > + if (memblk_nodeid[i] == node) {
> > + bool mismatch = !(ma->flags &
> > + ACPI_SRAT_MEM_HOT_PLUGGABLE) !=
> > + !test_bit(i, memblk_hotplug);
>
> Style: The middle line wants indenting by two more characters.
>
Yes, I will do it.
> > +
> > + printk("%sSRAT: PXM %u (%"PRIpaddr"-%"PRIpaddr")
> overlaps with itself (%"PRIpaddr"-%"PRIpaddr")\n",
> > + mismatch ? KERN_ERR : KERN_WARNING, pxm, start,
> > + end, node_memblk_range[i].start,
> > + node_memblk_range[i].end);
> > + if (mismatch) {
> > + bad_srat();
> > + return;
> > + }
> > + } else {
> > + printk(KERN_ERR
> > + "SRAT: PXM %u (%"PRIpaddr"-%"PRIpaddr") overlaps
> with PXM %u (%"PRIpaddr"-%"PRIpaddr")\n",
> > + pxm, start, end, node_to_pxm(memblk_nodeid[i]),
> > + node_memblk_range[i].start,
> > + node_memblk_range[i].end);
> > bad_srat();
> > return;
> > }
> > - } else {
> > + } else if (status == ERR_INTERLEAVE) {
> > printk(KERN_ERR
> > - "SRAT: PXM %u (%"PRIpaddr"-%"PRIpaddr") overlaps with
> PXM %u (%"PRIpaddr"-%"PRIpaddr")\n",
> > - pxm, start, end, node_to_pxm(memblk_nodeid[i]),
> > + "SRAT: Node %u: (%"PRIpaddr"-%"PRIpaddr") interleaves
> with node %u memblk (%"PRIpaddr"-%"PRIpaddr")\n",
> > + node, nd_start, nd_end, memblk_nodeid[i],
>
> Please log pxm (not node) here just like is done in the overlap case.
> The remote node ID will then require converting to PXM, of course.
>
Ok, will use PXM here. But I have question for upcoming changes, if we
move this part of code to common. As device tree NUMA doesn't have
PXM concept (even I can use a fake node_to_pxm to do 1:1 mapping), so
can we still use PXM here?
> Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |