From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bill Burns Subject: Re: RFC: large system support - 128 CPUs Date: Wed, 13 Aug 2008 06:23:13 -0400 Message-ID: <48A2B611.8010904@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: 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 Cc: xen-devel , Tim Deegan List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > On 13/8/08 09:22, "Tim Deegan" wrote: > >> At 09:21 +0100 on 13 Aug (1218619274), Jan Beulich wrote: >>> Both seem to be hacks to get to 128 CPUs, without consideration of how >>> to go beyond that >> I think the shadow_page_info one is a general fix for my implicit >> assumption that sizeof(cpumask_t) == sizeof (long). > > Do some fields after the cpumask need to line up in both structures? Placing > a dummy cpumask in the shadow_page structure might make most sense. Yes, there is a check that a field of page_info and a field of the shadow_page_info are at the same offset. Both compile time checks are in private.h > > For the other one I'll have to think a bit. The need for GDT entries per CPU > currently obviously means scaling much past a few hundred CPUs is going to > be difficult. Yes, would like something better here. And as I said, we don't know yet that just adding the additional page solves anything. Bill > > -- Keir > >