qemu-arm
[Top][All Lists]
Advanced

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

Re: [Qemu-arm] MPIDR Aff0 question


From: Andrew Jones
Subject: Re: [Qemu-arm] MPIDR Aff0 question
Date: Fri, 5 Feb 2016 13:08:50 +0100
User-agent: Mutt/1.5.23.1 (2014-03-12)

On Fri, Feb 05, 2016 at 11:00:33AM +0000, Mark Rutland wrote:
> On Fri, Feb 05, 2016 at 10:23:53AM +0100, Andrew Jones wrote:
> > On Thu, Feb 04, 2016 at 06:51:06PM +0000, Marc Zyngier wrote:
>  > What would the benefit of defining a "socket"?
> > 
> > That's a good lead in for my next question. While I don't believe
> > there needs to be any relationship between socket and numa node, I
> > suspect on real machines there is, and quite possibly socket == node.
> > Shannon is adding numa support to QEMU right now. Without special
> > configuration there's no gain other than illusion, but with pinning,
> > etc. the guest numa nodes will map to host nodes, and thus passing
> > that information on to the guest's kernel is useful. Populating a
> > socket/node affinity field seems to me like a needed step. But,
> > question time, is it? Maybe not. 
> 
> I don't think it's necessary.
> 
> When using ACPI, NUMA info comes from SRAT+SLIT, and the MPIDR.Aff*
> fields do not provide NUMA topology info. I expect the same to be true
> with DT using something like numa-distance-map [1].

Thanks Mark. So it appears my NUMA connection was just muddying the
water. Modeling sockets may or may not have any value to a guest,
but in any case it's a separate issue.

> 
> > Also, the way Linux currently handles non-thread using MPIDRs
> > (Aff1:socket, Aff0:core) throws a wrench at the Aff2:socket,
> > Aff1:"cluster", Aff0:core(max 16) plan.  Either the plan or Linux
> > would need to be changed.
> 
> The topology can be explicitly overridden in DT using cpu-map [2]. I
> don't know what the story for ACPI is.

Thanks for the cpu-map pointer. That was indeed the piece I'd missed
that allows me to make sense of MPIDR affinity level use. I think I'll
still look into modeling sockets/cores/threads with QEMU, by also
adding cpu-map generation. I'll look into what the ACPI equivalent is
as well.

drew

> 
> Mark.
> 
> [1] 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/404057.html
> [2] 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/arm/topology.txt?h=v4.5-rc2&id=36f90b0a2ddd60823fe193a85e60ff1906c2a9b3



reply via email to

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