[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <d30f2c24-c876-ba2f-172e-eda71e404e7b@oracle.com>
Date: Thu, 1 Sep 2016 22:03:11 -0400
From: Boris Ostrovsky <boris.ostrovsky@...cle.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: david.vrabel@...rix.com, jgross@...e.com,
xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] xen/x86: Convert to hotplug state machine
On 08/31/2016 12:15 PM, Sebastian Andrzej Siewior wrote:
> On 2016-08-26 15:37:38 [-0400], Boris Ostrovsky wrote:
>>> If you do find the time, you might manage to rework the code to avoid
>>> using the _nocalls() function. If see this right, you use
>>> xen_setup_vcpu_info_placement() for the init in the first place. This
>>> uses for_each_possible_cpu macro. The cpuhp_setup_state() function would
>>> perform the init for all CPUs before they come up.
>> I am not sure I see what this would buy us.
>>
>> Besides, cpuhp_setup_state() uses for_each_present_cpu().
> Correct. So you would avoid running the init code on CPUs which are
> within the for_each_possible_cpu() set but not in for_each_present_cpu().
>
> Assuming a NUMA box with two CPUs, 8 cores each gives you 32 CPUs in
> Linux with hyper threading. BIOS may report 240 CPUs as the upper limit
> (possible CPUs) but if you never deploy them you don't need to
> initialize them… Should they be plugged physically then the
> for_each_present_cpu() loop will cover them once they come up.
>
That's not going to help Xen guests: all possible CPUs are brought up
right away and then those that are not in use are unplugged.
-boris
Powered by blists - more mailing lists