[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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





ä 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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.