All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eduardo Habkost <ehabkost@redhat.com>
To: Andrew Jones <drjones@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	He Chen <he.chen@linux.intel.com>,
	qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>,
	qemu-arm@nongnu.org, Shannon Zhao <zhaoshenglong@huawei.com>,
	Igor Mammedov <imammedo@redhat.com>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH v3] Allow setting NUMA distance for different NUMA nodes
Date: Thu, 30 Mar 2017 17:56:50 -0300	[thread overview]
Message-ID: <20170330205650.GR3709@thinpad.lan.raisama.net> (raw)
In-Reply-To: <20170330152626.ndf2lvh3vz2u5gnw@kamzik.brq.redhat.com>

On Thu, Mar 30, 2017 at 05:26:26PM +0200, Andrew Jones wrote:
> 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 <he.chen@linux.intel.com> 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.

I doubt anybody would ever use that option, either.

> 
> 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.

Sounds good to me.

-- 
Eduardo

      reply	other threads:[~2017-03-30 20:57 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-22  9:32 [Qemu-devel] [PATCH v3] Allow setting NUMA distance for different NUMA nodes He Chen
2017-03-22 10:34 ` Andrew Jones
2017-03-23  7:23   ` He Chen
2017-03-23  7:44     ` Andrew Jones
2017-03-23 13:52     ` Eric Blake
2017-03-23  9:29 ` Igor Mammedov
2017-03-29  8:50   ` He Chen
2017-03-29 11:44     ` Igor Mammedov
2017-03-29 12:30       ` Andrew Jones
2017-03-30 15:00         ` Eduardo Habkost
2017-03-30 15:26           ` Andrew Jones
2017-03-30 20:56             ` Eduardo Habkost [this message]

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=20170330205650.GR3709@thinpad.lan.raisama.net \
    --to=ehabkost@redhat.com \
    --cc=armbru@redhat.com \
    --cc=drjones@redhat.com \
    --cc=he.chen@linux.intel.com \
    --cc=imammedo@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=zhaoshenglong@huawei.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 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.