[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 02/10] numa: introduce MachineClass::forbid_asymmetrical_numa
From: |
Eduardo Habkost |
Subject: |
Re: [PATCH 02/10] numa: introduce MachineClass::forbid_asymmetrical_numa |
Date: |
Thu, 20 Aug 2020 12:51:03 -0400 |
On Thu, Aug 20, 2020 at 02:15:04PM +1000, 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.
>
> 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.
Requiring both QEMU (and possibly management software) to be
patched again after the guest kernel is fixed sounds undesirable.
Perhaps a warning would be better in this case?
In either case, it sounds like this won't be a common constraint
and I now agree with your original suggestion of doing this in
machine initialization code.
--
Eduardo
- [PATCH 06/10] spapr: allow 4 NUMA levels in ibm, associativity-reference-points, (continued)
- [PATCH 06/10] spapr: allow 4 NUMA levels in ibm, associativity-reference-points, Daniel Henrique Barboza, 2020/08/15
- [PATCH 10/10] specs/ppc-spapr-numa: update with new NUMA support, Daniel Henrique Barboza, 2020/08/15
- [PATCH 05/10] spapr: make ibm, max-associativity-domains scale with user input, Daniel Henrique Barboza, 2020/08/15
- [PATCH 02/10] numa: introduce MachineClass::forbid_asymmetrical_numa, Daniel Henrique Barboza, 2020/08/15
- Re: [PATCH 02/10] numa: introduce MachineClass::forbid_asymmetrical_numa, David Gibson, 2020/08/19
- Re: [PATCH 02/10] numa: introduce MachineClass::forbid_asymmetrical_numa,
Eduardo Habkost <=
- Re: [PATCH 02/10] numa: introduce MachineClass::forbid_asymmetrical_numa, Igor Mammedov, 2020/08/21
- Re: [PATCH 02/10] numa: introduce MachineClass::forbid_asymmetrical_numa, Daniel Henrique Barboza, 2020/08/21
- Re: [PATCH 02/10] numa: introduce MachineClass::forbid_asymmetrical_numa, David Gibson, 2020/08/24
- Re: [PATCH 02/10] numa: introduce MachineClass::forbid_asymmetrical_numa, Daniel Henrique Barboza, 2020/08/24
- Re: [PATCH 02/10] numa: introduce MachineClass::forbid_asymmetrical_numa, David Gibson, 2020/08/24
- Re: [PATCH 02/10] numa: introduce MachineClass::forbid_asymmetrical_numa, Daniel Henrique Barboza, 2020/08/25
- Re: [PATCH 02/10] numa: introduce MachineClass::forbid_asymmetrical_numa, David Gibson, 2020/08/25