Hi Jonathan, Thank you for looking at here! On Tue, Oct 08, 2024 at 11:30:38AM +0100, Jonathan Cameron wrote: > Date: Tue, 8 Oct 2024 11:30:38 +0100 > From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> > Subject: Re: [RFC v2 00/12] Introduce Hybrid CPU Topology via Custom > Topology Tree > X-Mailer: Claws Mail 4.1.0 (GTK 3.24.33; x86_64-w64-mingw32) > > On Thu, 19 Sep 2024 14:11:16 +0800 > Zhao Liu <zhao1.liu@xxxxxxxxx> wrote: > > > > -smp maxsockets=1,maxdies=1,maxmodules=2,maxcores=2,maxthreads=2 > > -machine pc,custom-topo=on \ > > -device cpu-socket,id=sock0 \ > > -device cpu-die,id=die0,bus=sock0 \ > > -device cpu-module,id=mod0,bus=die0 \ > > -device cpu-module,id=mod1,bus=die0 \ > > -device x86-intel-core,id=core0,bus=mod0 \ > > -device x86-intel-atom,id=core1,bus=mod1 \ > > -device x86-intel-atom,id=core2,bus=mod1 \ > > -device host-x86_64-cpu,id=cpu0,socket-id=0,die-id=0,module-id=0,core-id=0,thread-id=0 \ > > -device host-x86_64-cpu,id=cpu1,socket-id=0,die-id=0,module-id=0,core-id=0,thread-id=1 \ > > -device host-x86_64-cpu,id=cpu2,socket-id=0,die-id=0,module-id=1,core-id=0,thread-id=0 \ > > -device host-x86_64-cpu,id=cpu3,socket-id=0,die-id=0,module-id=1,core-id=1,thread-id=0 > > I quite like this as a way of doing the configuration but that needs > some review from others. Thanks! > Peter, Alex, do you think this scheme is flexible enough to ultimately > allow us to support this for arm? I was also hoping that being generic enough would benefit ARM. > > > > This does not accommodate hybrid topologies. Therefore, we introduce > > max* parameters: maxthreads/maxcores/maxmodules/maxdies/maxsockets > > (for x86), to predefine the topology framework for the machine. These > > parameters also constrain subsequent custom topologies, ensuring the > > number of child devices under each parent device does not exceed the > > specified max limits. > > To my thinking this seems like a good solution even though it's a > bunch more smp parameters. > > What does this actually mean for hotplug of CPUs? What cases work > with this setup? My solution for this does not change the current CPU hotplug, because the current cpu hotplug only needs to consider smp.cpus and smp.maxcpus. But when a cpu is plugged in, machine needs to make sure that plugging into the core doesn't break the maxthreads limit. Similarly, if one wants to support hotplugging at the socket/die/core granularity, he will need to make sure that the new topology meets the limits set by the max parameters, which are the equivalent of preemptively leaving some empty holes that can be utilized by hotplug. > > Therefore, once user wants to customize topology by "-machine > > custom-topo=on", the machine, that supports custom topology, will skip > > the default topology creation as well as the default CPU creation. > > Seems sensible to me. Thank you! Glad to have your support. Regards, Zhao
