Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1473656

Re: [PATCH 1/2] xen/x86: Convert to hotplug state machine

From Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Newsgroups linux.kernel
Subject Re: [PATCH 1/2] xen/x86: Convert to hotplug state machine
Date 2016-08-31 18:20 +0200
Message-ID <scgp5-4D4-41@gated-at.bofh.it> (permalink)
References <s6rdv-6L9-5@gated-at.bofh.it> <s6rdv-6L9-3@gated-at.bofh.it> <s74yd-6XD-7@gated-at.bofh.it> <sav8S-2RX-35@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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.

Sebastian

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [PATCH 1/2] xen/x86: Convert to hotplug state machine Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2016-08-26 21:40 +0200
  Re: [PATCH 1/2] xen/x86: Convert to hotplug state machine Sebastian Andrzej Siewior <bigeasy@linutronix.de> - 2016-08-31 18:20 +0200
    Re: [PATCH 1/2] xen/x86: Convert to hotplug state machine Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2016-09-02 04:10 +0200

csiph-web