Re: [Xen-devel] kernel bootup slow issue on ovm3.1.1

["zhenzhong.duan" <zhenzhong.duan@xxxxxxxxxx>]

ä 2012-08-07 16:37, Jan Beulich åé:
> > > > On 07.08.12 at 09:22, "zhenzhong.duan"<zhenzhong.duan@xxxxxxxxxx>  wrote:
> > 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?
> First of all it would have been useful to indicate the kernel version,
> since mtrr_work_handler() disappeared after 3.0. Obviously worth
> checking whether that change by itself already addresses your
> problem.
No luck, tried upstream kernel 3.6.0-rc1, seems worse. It took 2 hours 
to boot up.
> Next, if you already spotted where the spinning occurs, you
> should also be able to tell what's going on at the other side, i.e.
> why the event that is being waited for isn't occurring for this
> long a time. Since there's a number of open coded spin loops
> here, knowing exactly which one each CPU is sitting in (and
> which ones might not be in any) is the fundamental information
> needed.
>
>  From what you're telling us so far, I'd rather suspect a kernel
> problem, not a hypervisor one here.
Per my finding, most of vcpus spin at set_atomicity_lock. Some spin at 
stop_machine after finish their job.
Only one vcpu is calling generic_set_all.
I'm not sure if the vcpu calling generic_set_all don't have higher 
priority and maybe preempt by other vcpus and dom0 frequently.
This waste much time.
> Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel