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

RE: [PATCH v3 03/17] xen/arm: implement node distance helpers for Arm


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Henry Wang <Henry.Wang@xxxxxxx>
  • Date: Sun, 23 Apr 2023 05:36:42 +0000
  • Accept-language: zh-CN, en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.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=CNWTjDvMEVcE72DbqkZ3VeLOC1bIZOdNtEBHrdX2ho0=; b=nKafVI0zyzFIvifOPKfsT2THQQ3frTQ2xJx3aYgwcAxhUaGGx+HAmTPEhrVoyhFFwFh8UZAvkomKE3KZovbjwSuQggfbzefR0icyjlz0nZTrBfhNrz5VL9i5sZAcqlmtELm8QpiAnnjUltoRfdlPtwR/Q3gsM1nhOpgS5Lp2pqUOiFE0RAM38D4kDN5xEjwI/i5Rs3O5P2qqvuw3Aum/wqDvHIsjskz1R4tS9+1ZE801a14R1JlTNGyUVW3FuJZs5+TSCH8/Pex86+hwY1usXBeWOq7uXnkCuuQKEYwX6EtG7F5vLbKEDW/3STrIiMGsFH5Jq5wzHP5mMF3yLJUzpg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=X6ohWziq5y2xc8PFRhEscMmexQ+blJ+Km+g46oRlir7dqYsUhAPvFf2WhCeDMwKtOpPPoE4tflpUNU3UdSOX3UTfIHJayD4UUOCL3w0jxGq9w8pxLrR+mikQU9RNwewywvPjcRyJIGuQ0mgc43XlKLWGB7LElPc12vR2fsGmyKfcpQ6dvYBMyO8Bly9uNYGocKm1eQgiDNjYo1jxr3c/l2EfCF7aGYUAH5hEtG+uY9W/YZR7GvGPvP4CN6X9TUxh0Z+ipEO5qu9jwin8+KhXfT7E+Nqd2PjDkpTZyzZm/oaUKhiC2HL4mNJ8gaxAWU0rEQ4fAILwl6gLpO/juEDkJQ==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: Wei Chen <Wei.Chen@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Sun, 23 Apr 2023 05:37:17 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Thread-index: AQHZc3rmCrt50C+BaEmmIgaK9uo9ea80IxGAgAFPzpCAABDqgIAC3lpQ
  • Thread-topic: [PATCH v3 03/17] xen/arm: implement node distance helpers for Arm

Hi Jan,

> -----Original Message-----
> From: Jan Beulich <jbeulich@xxxxxxxx>
> Subject: Re: [PATCH v3 03/17] xen/arm: implement node distance helpers for
> Arm
> >> However, looking at the code below, don't you mean to have the array
> >> pre-set to all NUMA_NO_DISTANCE?
> >
> > ...I am a bit puzzled about why pre-setting the array to all
> > NUMA_NO_DISTANCE matters here, as I think the node distance map will
> > be populated when parsing the device tree anyway no matter what their
> > initial values.
> 
> From this patch alone it doesn't become clear whether indeed all array
> slots (and not just ones for valid nodes) would be populated. I think
> the code in the patch here would better not make itself dependent on
> behavior of code added subsequently (which may change; recall that a
> series may be committed in pieces).

Correct, I agree. I added a numa_init_distance() function (in patch #12) to
set all values to NUMA_NO_DISTANCE. The numa_init_distance() will be
called in the beginning of numa_init().

> 
> >>> +unsigned char __node_distance(nodeid_t from, nodeid_t to)
> >>> +{
> >>> +    /* When NUMA is off, any distance will be treated as remote. */
> >>> +    if ( numa_disabled() )
> >>> +        return NUMA_REMOTE_DISTANCE;
> >>
> >> Wouldn't it make sense to have the "from == to" special case ahead of
> >> this (rather than further down), thus yielding a sensible result for
> >> from == to == 0? And else return NUMA_NO_DISTANCE, thus having a
> >> sensible result also for any from/to != 0?
> >
> > Could you please elaborate a bit more about why 0 matters here?
> 
> When NUMA is off, there's only one node - node 0. Hence 0 has special
> meaning in that case.
> 
> > As from my understanding,
> > (1) If from == to, then we set the distance to NUMA_LOCAL_DISTANCE
> > which represents the diagonal of the matrix.
> > (2) If from and to is in the matrix range, then we return
> > node_distance_map[from][to].
> 
> Provided that's set correctly. IOW this interacts with the other comment
> (which really I made only after the one here, just that that's of course
> not visible from the reply that I sent).
> 
> > (3) Other cases we return NUMA_NO_DISTANCE.
> 
> And when NUMA is off, it should be NUMA_NO_DISTANCE in _all_ other
> cases,
> i.e. ...
> 
> >      /* When NUMA is off, any distance will be treated as remote. */
> >      if ( numa_disabled() )
> >          return NUMA_REMOTE_DISTANCE;
> 
> ... this return is wrong in that case (even if in reality this likely
> wouldn't matter much).

Thanks for the explanation! I think I now understand :) Would this diff below
look good to you then? Appreciate your patience.

unsigned char __node_distance(nodeid_t from, nodeid_t to)
 {
-    /* When NUMA is off, any distance will be treated as remote. */
+    if ( from == to )
+        return NUMA_LOCAL_DISTANCE;
+
+    /* When NUMA is off, any distance will be treated as unreachable (0xFF). */
     if ( numa_disabled() )
-        return NUMA_REMOTE_DISTANCE;
+        return NUMA_NO_DISTANCE;

     /*
      * Check whether the nodes are in the matrix range.
      * When any node is out of range, except from and to nodes are the
-     * same, we treat them as unreachable (return 0xFF)
+     * same, we treat them as unreachable (0xFF)
      */
     if ( from >= ARRAY_SIZE(node_distance_map) ||
          to >= ARRAY_SIZE(node_distance_map[0]) )
-        return from == to ? NUMA_LOCAL_DISTANCE : NUMA_NO_DISTANCE;
+        return NUMA_NO_DISTANCE;

     return node_distance_map[from][to];
 }

Kind regards,
Henry

> 
> Jan
> 

 


Rackspace

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