qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Andrew Jones <drjones@redhat.com>
Cc: peter.maydell@linaro.org, Gavin Shan <gshan@redhat.com>,
	ehabkost@redhat.com, qemu-devel@nongnu.org, qemu-arm@nongnu.org,
	shan.gavin@gmail.com
Subject: Re: [PATCH 1/2] numa: Set default distance map if needed
Date: Tue, 12 Oct 2021 14:34:30 +0200	[thread overview]
Message-ID: <20211012143430.17b7ca99@redhat.com> (raw)
In-Reply-To: <20211012114802.u3og3lmei35qacpx@gator>

On Tue, 12 Oct 2021 13:48:02 +0200
Andrew Jones <drjones@redhat.com> wrote:

> On Tue, Oct 12, 2021 at 09:31:55PM +1100, Gavin Shan wrote:
> > Hi Igor,
> > 
> > On 10/12/21 8:40 PM, Igor Mammedov wrote:  
> > > On Wed,  6 Oct 2021 18:22:08 +0800
> > > Gavin Shan <gshan@redhat.com> wrote:
> > >   
> > > > The following option is used to specify the distance map. It's
> > > > possible the option isn't provided by user. In this case, the
> > > > distance map isn't populated and exposed to platform. On the
> > > > other hand, the empty NUMA node, where no memory resides, is
> > > > allowed on ARM64 virt platform. For these empty NUMA nodes,
> > > > their corresponding device-tree nodes aren't populated, but
> > > > their NUMA IDs should be included in the "/distance-map"
> > > > device-tree node, so that kernel can probe them properly if
> > > > device-tree is used.
> > > > 
> > > >    -numa,dist,src=<numa_id>,dst=<numa_id>,val=<distance>
> > > > 
> > > > So when user doesn't specify distance map, we need to generate
> > > > the default distance map, where the local and remote distances
> > > > are 10 and 20 separately. This adds an extra parameter to the
> > > > exiting complete_init_numa_distance() to generate the default
> > > > distance map for this case.
> > > > 
> > > > Signed-off-by: Gavin Shan <gshan@redhat.com>  
> > > 
> > > 
> > > how about error-ing out if distance map is required but
> > > not provided by user explicitly and asking user to fix
> > > command line?
> > > 
> > > Reasoning behind this that defaults are hard to maintain
> > > and will require compat hacks and being raod blocks down
> > > the road.
> > > Approach I was taking with generic NUMA code, is deprecating
> > > defaults and replacing them with sanity checks, which bail
> > > out on incorrect configuration and ask user to correct command line.
> > > Hence I dislike approach taken in this patch.
> > > 
> > > If you really wish to provide default, push it out of
> > > generic code into ARM specific one
> > > (then I won't oppose it that much (I think PPC does
> > > some magic like this))
> > > Also behavior seems to be ARM specific so generic
> > > NUMA code isn't a place for it anyways
> > >   
> > 
> > Thanks for your comments.
> > 
> > Yep, Lets move the logic into hw/arm/virt in v3 because I think simply
> > error-ing out will block the existing configuration where the distance
> > map isn't provided by user. After moving the logic to hw/arm/virt,
> > this patch is consistent with PATCH[02/02] and the specific platform
> > is affected only.  
> 
> Please don't move anything NUMA DT generic to hw/arm/virt. If the spec
> isn't arch-specific, then the modeling shouldn't be either.


> If you want to error-out for all configs missing the distance map, then
> you'll need compat code.

> If you only want to error-out for configs that
> have empty NUMA nodes and are missing a distance map, then you don't
> need compat code, because those configs never worked before anyway.

I think memory-less configs without distance map worked for x86 just fine.

After looking at this thread all over again it seems to me that using
distance map as a source of numa ids is a mistake.


> 
> Thanks,
> drew
> 
> > 
> >   
> > > > ---
> > > >   hw/core/numa.c | 13 +++++++++++--
> > > >   1 file changed, 11 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/hw/core/numa.c b/hw/core/numa.c
> > > > index 510d096a88..fdb3a4aeca 100644
> > > > --- a/hw/core/numa.c
> > > > +++ b/hw/core/numa.c
> > > > @@ -594,7 +594,7 @@ static void validate_numa_distance(MachineState *ms)
> > > >       }
> > > >   }
> > > > -static void complete_init_numa_distance(MachineState *ms)
> > > > +static void complete_init_numa_distance(MachineState *ms, bool is_default)
> > > >   {
> > > >       int src, dst;
> > > >       NodeInfo *numa_info = ms->numa_state->nodes;
> > > > @@ -609,6 +609,8 @@ static void complete_init_numa_distance(MachineState *ms)
> > > >               if (numa_info[src].distance[dst] == 0) {
> > > >                   if (src == dst) {
> > > >                       numa_info[src].distance[dst] = NUMA_DISTANCE_MIN;
> > > > +                } else if (is_default) {
> > > > +                    numa_info[src].distance[dst] = NUMA_DISTANCE_DEFAULT;
> > > >                   } else {
> > > >                       numa_info[src].distance[dst] = numa_info[dst].distance[src];
> > > >                   }
> > > > @@ -716,13 +718,20 @@ void numa_complete_configuration(MachineState *ms)
> > > >            * A->B != distance B->A, then that means the distance table is
> > > >            * asymmetric. In this case, the distances for both directions
> > > >            * of all node pairs are required.
> > > > +         *
> > > > +         * The default node pair distances, which are 10 and 20 for the
> > > > +         * local and remote nodes separatly, are provided if user doesn't
> > > > +         * specify any node pair distances.
> > > >            */
> > > >           if (ms->numa_state->have_numa_distance) {
> > > >               /* Validate enough NUMA distance information was provided. */
> > > >               validate_numa_distance(ms);
> > > >               /* Validation succeeded, now fill in any missing distances. */
> > > > -            complete_init_numa_distance(ms);
> > > > +            complete_init_numa_distance(ms, false);
> > > > +        } else {
> > > > +            complete_init_numa_distance(ms, true);
> > > > +            ms->numa_state->have_numa_distance = true;
> > > >           }
> > > >       }
> > > >   }  
> > >   
> > 
> > Thanks,
> > Gavin
> >   
> 



  reply	other threads:[~2021-10-12 12:36 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-06 10:22 [PATCH 0/2] hw/arm/virt: Fix qemu booting failure on device-tree Gavin Shan
2021-10-06 10:22 ` [PATCH 1/2] numa: Set default distance map if needed Gavin Shan
2021-10-06 10:35   ` Andrew Jones
2021-10-06 11:03     ` Gavin Shan
2021-10-06 11:56       ` Andrew Jones
2021-10-07 23:51         ` Gavin Shan
2021-10-08  6:07           ` Andrew Jones
2021-10-12  6:13             ` Gavin Shan
2021-10-12  9:40   ` Igor Mammedov
2021-10-12 10:31     ` Gavin Shan
2021-10-12 11:18       ` Igor Mammedov
2021-10-12 11:48       ` Andrew Jones
2021-10-12 12:34         ` Igor Mammedov [this message]
2021-10-12 13:05           ` Andrew Jones
2021-10-12 22:59             ` Gavin Shan
2021-10-12 10:37     ` Andrew Jones
2021-10-12 12:27       ` Igor Mammedov
2021-10-12 13:13         ` Andrew Jones
2021-10-12 13:53           ` Igor Mammedov
2021-10-12 23:32             ` Gavin Shan
2021-10-13  9:32               ` Igor Mammedov
2021-10-13  6:29             ` Andrew Jones
2021-10-06 10:22 ` [PATCH 2/2] hw/arm/virt: Don't create device-tree node for empty NUMA node Gavin Shan
2021-10-06 10:36   ` Andrew Jones

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=20211012143430.17b7ca99@redhat.com \
    --to=imammedo@redhat.com \
    --cc=drjones@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=gshan@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=shan.gavin@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).