From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: RE: [PATCH] Allocate vmcs pages when system booting Date: Thu, 18 Mar 2010 10:45:21 +0000 Message-ID: <4BA212510200007800035AF5@vpn.id2.novell.com> References: <4B5043B8020000780002A2E9@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser , Yunhong Jiang Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org >>> Keir Fraser 15.01.10 11:31 >>> >On 15/01/2010 09:30, "Jan Beulich" wrote: > >>>>> "Jiang, Yunhong" 15.01.10 10:06 >>> >>> b) Can we still turn to the original patch, i.e. pre-allocate all VMCS = pages >>> for all possible CPU? >>=20 >> I'm generally opposed to pre-allocations, at least as long as all CPUs = are >> considered 'possible'. Building with a relatively high nr_cpus=3D = setting >> and then running on a relatively small system results in (close to) >> unacceptable overhead. >>=20 >> In fact it's really not clear to me why cpu_possible_map must be set to >> CPU_MASK_ALL - if Linux has ways to avoid this, Xen should have too. > >Does Linux manage a good reliable job of cutting down cpu_possible_map? = That >would save cpu_possible_map in my eyes, if we could do that. Otherwise it = is >indeed pretty useless now. Either way, I'd like cpu hotplug notifier = chains >in the 4.1 development window. Only now got to look into this: Linux simply counts the disabled CPUs along with the present ones, plus it allows a command line override to the number of CPU slots reserved for hotplug. I just put together something similar, partly copying code over from there. Will submit post-4.0. Jan