From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bill Burns Subject: Re: Test results on Unisys ES7000 64x 256gb using unstable c/s 16693 on 3.2.0 Release Candidate Date: Tue, 15 Jan 2008 08:50:23 -0500 Message-ID: <478CBA1F.5070701@redhat.com> References: <089B0D75973E1241B941D0A9854F23FC0A6125EC@USEA-EXCH2.na.uis.unisys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <089B0D75973E1241B941D0A9854F23FC0A6125EC@USEA-EXCH2.na.uis.unisys.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Carb, Brian A" Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Carb, Brian A wrote: > Test results on Unisys ES7000 64x 256gb using unstable c/s 16693 on > 3.2.0 Release Candidate > > HOST: > Unisys ES7000/one, x86_64, 64 processors, 256gb memory > unstable changeset 16693 compiled with max_phys_cpus=64 and booted with > dom0_mem=4096M, numa=on, and xenheap_megabytes=64 > from http://xenbits.xensource.com/staging/xen-unstable.hg pulled on > 20080108: > We have noticed problems with dom0 initialization when not limiting the memory for dom0 when we reach 112GB. This is using 3.1.2 and also appears in 3.1.3 as it stood last week. Note that 3.1.0 had no such issue. The problem is definately a Hypervisor change of some sort (as opposed to a dom0 kernel change). Wondering if anyone else sees this? And while it makes a lot of sense to limit dom0 memory we have not in the past. And it's somewhat problematic to know what to limit it too. We are in the process of trying to determine what change set introduced this regression. Thanks, Bill