From: Daniel Henrique Barboza <danielhb413@gmail.com>
To: David Gibson <david@gibson.dropbear.id.au>,
Eduardo Habkost <ehabkost@redhat.com>
Cc: qemu-ppc@nongnu.org, John Snow <jsnow@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [PATCH 02/10] numa: introduce MachineClass::forbid_asymmetrical_numa
Date: Thu, 20 Aug 2020 07:33:00 -0300 [thread overview]
Message-ID: <6086c921-9eb5-5bc6-7af3-b914f13f1f2f@gmail.com> (raw)
In-Reply-To: <20200820041504.GN271315@yekko.fritz.box>
On 8/20/20 1:15 AM, David Gibson wrote:
> On Wed, Aug 19, 2020 at 10:11:28PM -0400, Eduardo Habkost wrote:
>> On Thu, Aug 20, 2020 at 11:17:26AM +1000, David Gibson wrote:
>>> On Fri, Aug 14, 2020 at 05:54:16PM -0300, Daniel Henrique Barboza wrote:
>>>> The pSeries machine does not support asymmetrical NUMA
>>>> configurations.
>>>
>>> This seems a bit oddly specific to have as a global machine class
>>> property.
>>>
>>> Would it make more sense for machines with specific NUMA constraints
>>> to just verify those during their initialization?
>>
>> This would be much simpler. However, I like the idea of
>> representing machine-specific configuration validation rules as
>> data that can eventually be exported to management software.
>
> Ah, ok, so basically the usual tradeoff between flexibility and
> advertisability.
To provide context, what I did here was inspired by this commit:
commit 0533ef5f2089f4f12a0ec5c8035e5e15ba0b5556
Author: Tao Xu <tao3.xu@intel.com>
Date: Thu Sep 5 16:32:38 2019 +0800
numa: Introduce MachineClass::auto_enable_numa for implicit NUMA node
In this commit, exclusive NUMA code from spapr.c was taken and put it
into numa.c, with a flag being set in spapr machine_init.
Thanks,
DHB
>
> So, in that case, I guess the question is whether we envisage "no
> assymmetry" as a constraint common enough that it's worth creating an
> advertisable rule or not. If we only ever have one user, then we
> haven't really done any better than hard coding the constraint in the
> manageent software.
>
> Of course to complicate matters, in the longer term we're looking at
> removing that constraint from pseries - but doing so will be dependent
> on the guest kernel understanding a new format for the NUMA
> information in the device tree. So qemu alone won't have enough
> information to tell if such a configuration is possible or not.
>
>> (CCing John Snow, who had spent some time thinking about
>> configuration validation recently.)
>>
>>
>>>>
>>>> CC: Eduardo Habkost <ehabkost@redhat.com>
>>>> CC: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
>>>> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
>>>> ---
>>>> hw/core/numa.c | 7 +++++++
>>>> hw/ppc/spapr.c | 1 +
>>>> include/hw/boards.h | 1 +
>>>> 3 files changed, 9 insertions(+)
>>>>
>>>> diff --git a/hw/core/numa.c b/hw/core/numa.c
>>>> index d1a94a14f8..1e81233c1d 100644
>>>> --- a/hw/core/numa.c
>>>> +++ b/hw/core/numa.c
>>>> @@ -547,6 +547,7 @@ static int parse_numa(void *opaque, QemuOpts *opts, Error **errp)
>>>> */
>>>> static void validate_numa_distance(MachineState *ms)
>>>> {
>>>> + MachineClass *mc = MACHINE_GET_CLASS(ms);
>>>> int src, dst;
>>>> bool is_asymmetrical = false;
>>>> int nb_numa_nodes = ms->numa_state->num_nodes;
>>>> @@ -575,6 +576,12 @@ static void validate_numa_distance(MachineState *ms)
>>>> }
>>>>
>>>> if (is_asymmetrical) {
>>>> + if (mc->forbid_asymmetrical_numa) {
>>>> + error_report("This machine type does not support "
>>>> + "asymmetrical numa distances.");
>>>> + exit(EXIT_FAILURE);
>>>> + }
>>>> +
>>>> for (src = 0; src < nb_numa_nodes; src++) {
>>>> for (dst = 0; dst < nb_numa_nodes; dst++) {
>>>> if (src != dst && numa_info[src].distance[dst] == 0) {
>>>> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
>>>> index dd2fa4826b..3b16edaf4c 100644
>>>> --- a/hw/ppc/spapr.c
>>>> +++ b/hw/ppc/spapr.c
>>>> @@ -4512,6 +4512,7 @@ static void spapr_machine_class_init(ObjectClass *oc, void *data)
>>>> */
>>>> mc->numa_mem_align_shift = 28;
>>>> mc->auto_enable_numa = true;
>>>> + mc->forbid_asymmetrical_numa = true;
>>>>
>>>> smc->default_caps.caps[SPAPR_CAP_HTM] = SPAPR_CAP_OFF;
>>>> smc->default_caps.caps[SPAPR_CAP_VSX] = SPAPR_CAP_ON;
>>>> diff --git a/include/hw/boards.h b/include/hw/boards.h
>>>> index bc5b82ad20..dc6cdd1c53 100644
>>>> --- a/include/hw/boards.h
>>>> +++ b/include/hw/boards.h
>>>> @@ -215,6 +215,7 @@ struct MachineClass {
>>>> bool nvdimm_supported;
>>>> bool numa_mem_supported;
>>>> bool auto_enable_numa;
>>>> + bool forbid_asymmetrical_numa;
>>>> const char *default_ram_id;
>>>>
>>>> HotplugHandler *(*get_hotplug_handler)(MachineState *machine,
>>>
>>
>>
>>
>
next prev parent reply other threads:[~2020-08-20 10:34 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-14 20:54 [PATCH 00/10] pseries NUMA distance rework Daniel Henrique Barboza
2020-08-14 20:54 ` [PATCH 01/10] hw: add compat machines for 5.2 Daniel Henrique Barboza
2020-08-14 20:54 ` [PATCH 02/10] numa: introduce MachineClass::forbid_asymmetrical_numa Daniel Henrique Barboza
2020-08-20 1:17 ` David Gibson
2020-08-20 2:11 ` Eduardo Habkost
2020-08-20 4:15 ` David Gibson
2020-08-20 10:33 ` Daniel Henrique Barboza [this message]
2020-08-20 14:29 ` Igor Mammedov
2020-08-20 16:51 ` Eduardo Habkost
2020-08-21 8:55 ` Igor Mammedov
2020-08-21 12:47 ` Daniel Henrique Barboza
2020-08-24 6:08 ` David Gibson
2020-08-24 11:45 ` Daniel Henrique Barboza
2020-08-24 23:49 ` David Gibson
2020-08-25 9:56 ` Daniel Henrique Barboza
2020-08-25 11:12 ` David Gibson
2020-09-23 15:21 ` John Snow
2020-08-14 20:54 ` [PATCH 03/10] spapr: robustify NVLink2 NUMA node logic Daniel Henrique Barboza
2020-08-20 2:14 ` David Gibson
2020-08-26 21:49 ` Daniel Henrique Barboza
2020-08-14 20:54 ` [PATCH 04/10] spapr: add spapr_machine_using_legacy_numa() helper Daniel Henrique Barboza
2020-08-20 2:15 ` David Gibson
2020-08-14 20:54 ` [PATCH 05/10] spapr: make ibm, max-associativity-domains scale with user input Daniel Henrique Barboza
2020-08-20 2:55 ` [PATCH 05/10] spapr: make ibm,max-associativity-domains " David Gibson
2020-08-26 21:17 ` Daniel Henrique Barboza
2020-08-14 20:54 ` [PATCH 06/10] spapr: allow 4 NUMA levels in ibm, associativity-reference-points Daniel Henrique Barboza
2020-08-14 20:54 ` [PATCH 07/10] spapr: create helper to set ibm,associativity Daniel Henrique Barboza
2020-08-20 3:00 ` David Gibson
2020-08-20 10:39 ` Daniel Henrique Barboza
2020-08-14 20:54 ` [PATCH 08/10] spapr: introduce SpaprMachineClass::numa_assoc_domains Daniel Henrique Barboza
2020-08-20 4:26 ` David Gibson
2020-08-26 20:06 ` Daniel Henrique Barboza
2020-08-14 20:54 ` [PATCH 09/10] spapr: consider user input when defining spapr guest NUMA Daniel Henrique Barboza
2020-08-14 20:54 ` [PATCH 10/10] specs/ppc-spapr-numa: update with new NUMA support Daniel Henrique Barboza
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=6086c921-9eb5-5bc6-7af3-b914f13f1f2f@gmail.com \
--to=danielhb413@gmail.com \
--cc=david@gibson.dropbear.id.au \
--cc=ehabkost@redhat.com \
--cc=jsnow@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
/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).