qemu-ppc
[Top][All Lists]
Advanced

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

Re: [PATCH 02/10] numa: introduce MachineClass::forbid_asymmetrical_numa


From: David Gibson
Subject: Re: [PATCH 02/10] numa: introduce MachineClass::forbid_asymmetrical_numa
Date: Tue, 25 Aug 2020 21:12:08 +1000

On Tue, Aug 25, 2020 at 06:56:46AM -0300, Daniel Henrique Barboza wrote:
> 
> 
> On 8/24/20 8:49 PM, David Gibson wrote:
> > On Mon, Aug 24, 2020 at 08:45:12AM -0300, Daniel Henrique Barboza wrote:
> > > 
> > > 
> 
> [...]
> 
> > > > > LOPAPR support a somewhat asymmetrical NUMA setup in its current
> > > > > form,
> > > > 
> > > > Huh, I didn't even realize that.  What's the mechanism?
> > > 
> > > LOPAPR mentions that a single resource/node can have multiple 
> > > associativity
> > > arrays. The idea is to contemplate the situations where the node has
> > > more than one connection with the board.
> > > 
> > > I say "somewhat" because, right after mentioning that, the spec also says 
> > > that
> > > the OS should consider that the distance between two nodes must always be
> > > the shortest one of all available arrays. I'll copy/paste the except here
> > > (end of section 15.2, "Numa Resource Associativity":
> > 
> > Ah.  I didn't think that's what "asymmetric NUMA" meant... but come to
> > think of it, I'm not very sure about that.
> 
> 
> This was a poor attempt of my part to cut PAPR some slack.
> 
> TBH, even if current PAPR allows for some form of NUMA asymmetry, I don't 
> think
> it's worth implementing at all. It'll be more complexity on top of what I
> already added here, and the best case scenario will be the kernel ignoring it
> (worst case - kernel blowing it up because we're adding more associativity
> arrays in each CPU and so on).

Yes, I agree.

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

Attachment: signature.asc
Description: PGP signature


reply via email to

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