qemu-arm
[Top][All Lists]
Advanced

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

Re: [Qemu-arm] [Qemu-devel] [PATCH v3] Allow setting NUMA distance for d


From: Andrew Jones
Subject: Re: [Qemu-arm] [Qemu-devel] [PATCH v3] Allow setting NUMA distance for different NUMA nodes
Date: Thu, 30 Mar 2017 17:26:26 +0200
User-agent: Mutt/1.6.0.1 (2016-04-01)

On Thu, Mar 30, 2017 at 12:00:48PM -0300, Eduardo Habkost wrote:
> On Wed, Mar 29, 2017 at 02:30:38PM +0200, Andrew Jones wrote:
> > On Wed, Mar 29, 2017 at 01:44:58PM +0200, Igor Mammedov wrote:
> > > On Wed, 29 Mar 2017 16:50:00 +0800
> > > He Chen <address@hidden> wrote:
> > > > > > +static void default_numa_distance(void)
> > > > > > +{
> > > > > > +    int src, dst;
> > > > > > +  
> > > > > fill in defaults only if there weren't any '-numa dist' on CLI
> > > > > and refuse to start if partial filled table were explicitly provided 
> > > > > on CLI
> > > > >   
> > > > I am afraid that I may have a bad function name here, fill_numa_distance
> > > > might be a better name?
> > > > 
> > > > Also, since the distance can be asymmetric, IMHO, providing a partial
> > > > filled table looks fine. If we set many NUMA nodes e.g. 8 nodes for
> > > > guest, the whole filled table would require many command lines which
> > > > might be inconvenient and less flexible.
> > > asymmetric doesn't imply sparse, so one has to specify full matrix
> > > it might be inconvenient /long/ but is very flexible.
> > 
> > This makes me realize that a user only inputting one of A -> B or B -> A
> > command line inputs doesn't imply symmetry.  It could be that the user
> > just forgot to input the opposite.  To avoid the ambiguity we either need
> > to force both to be input (as it was before I suggested otherwise), or
> > add a '-numa symmetric' type of property to enable the shortcut.  I guess
> > we should just avoid the shortcut, at least for now.
> 
> Is protecting the user from one very specific (and very rare[1])
> mistake a good reason for making the automatic default less
> useful?

Maybe not, but creating new interfaces with known ambiguities isn't ideal
either.

> Requiring an explicit '-numa symmetric' option to enable
> the automatic default seems to defeat the purpose of having an
> automatic default, to me.

We could reverse it, '-numa asymmetric' could turn off the defaults
and abort on an incomplete table.


Or, we could leave it ambiguous, but improve the heuristic by requiring
all directions be given if even one direction has an asymmetric reverse
path given. With that, there's still a chance to let user error slip
through, but much less. I could live with that.

Thanks,
drew



reply via email to

[Prev in Thread] Current Thread [Next in Thread]