From mboxrd@z Thu Jan  1 00:00:00 1970
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: kernel bootup slow issue on ovm3.1.1
Date: Tue, 7 Aug 2012 12:26:37 -0400
Message-ID: <20120807162637.GB15053@phenom.dumpdata.com>
References: <5020C24A.3060604@oracle.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Content-Disposition: inline
In-Reply-To: <5020C24A.3060604@oracle.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: "zhenzhong.duan" <zhenzhong.duan@oracle.com>
Cc: xen-devel@lists.xensource.com, Feng Jin <joe.jin@oracle.com>
List-Id: xen-devel@lists.xenproject.org

On Tue, Aug 07, 2012 at 03:22:50PM +0800, zhenzhong.duan wrote:
> Hi maintainers,
> 
> We meet a uek2 bootup slow issue on our ovm product(ovm3.0.3 and ovm3.1.1).
> 
> The system env is an exalogic node with 24 cores + 100G mem (2 socket ,
> 6 cores per socket, 2 HT threads per core).
> After boot up this node with all cores enabled,
> We boot a pvhvm with 12vpcus (or 24) + 90 GB + pci passthroughed device,
> it takes 30+ mins to boot.
> If we remove passthrough device from vm.cfg, bootup takes about 2 mins.
> If we use a small mem(eg. 10G + 24 vcpus), bootup takes about 3 mins.
> So a big mem + passthrough device made the worst case.
> 
> If we boot this node with HT disabled from BIOS. Now only 12 cores are
> available.
> OVM on same node, same config with 12vpcus+90GB boots in 1.5 mins!
> 
> After some debug, we found it's in kernel mtrr init that make this delay.
> 
> mtrr_aps_init() 
>  \-> set_mtrr() 
>      \-> mtrr_work_handler() 
> 
> kernel spin in mtrr_work_handler.
> 
> But we don't know the scene hide in the hypervisor. Why big mem +
> passthrough made the worst case.
> Is this already fixed in xen upstream?
> Any comments are welcome, I'll upload all data depend on your need.

What happens if you run with a upstream version of kernel? Say v3.4.7 ?
Do you see the same issue?
> 
> thanks
> zduan

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel