qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 7/9] pc: acpi: drop not needed intermediate bitm


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH 7/9] pc: acpi: drop not needed intermediate bitmap cpu->found_cpus
Date: Thu, 11 Feb 2016 13:59:33 -0200
User-agent: Mutt/1.5.23 (2014-03-12)

On Fri, Feb 05, 2016 at 05:44:49PM +0100, Igor Mammedov wrote:
> On Fri, 5 Feb 2016 17:19:50 +0100
> Igor Mammedov <address@hidden> wrote:
> 
> > On Fri, 5 Feb 2016 13:39:07 -0200
> > Eduardo Habkost <address@hidden> wrote:
> > 
> > > On Thu, Feb 04, 2016 at 12:47:33PM +0100, Igor Mammedov wrote:  
> > > > cpu->found_cpus bitmap is used for setting present
> > > > flag in CPON AML package at start up. But it takes
> > > > a bunch of code to fill bitmap and cloud be simplified
> > > > by calling qemu_get_cpu_by_arch_id(apic_id) directly.
> > > > 
> > > > Hence do so and remove not used anymore bitmap
> > > > with related utilities, which saves us ~32LOC
> > > > and also would simplify consolidating APCI parts
> > > > of CPU hotplug.
> > > > 
> > > > Signed-off-by: Igor Mammedov <address@hidden>    
> > > 
> > > This makes the code loops through all smp_cpus CPUs max_cpus
> > > times, instead of just looping through the smp_cpus CPUs once.  
> > Yep, that looks bad.
> > I'll redo it using possible_cpu_arch_ids(), it is a little
> > bit bigger refactoring.
> I think I'll make bitmap local to build_processor_devices() as it's
> needed only for building CPON package, that way it will go along
> with related legacy hotplug and won't get in the way of new hotplug.

What about pc_possible_cpu_arch_ids() itself? It has exactly the
same problem: it looks at CPU objects smp_cpus*max_cpus times, to
fill the CPUArchId.cpu field. If that's a problem for
build_processor_devices(), I assume that's a problem for all
other possible_cpu_arch_ids() callers?

-- 
Eduardo



reply via email to

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