Re: kernel bootup slow issue on ovm3.1.1

["zhenzhong.duan" <zhenzhong.duan@oracle.com>]

于 2012-08-07 16:37, Jan Beulich 写道:
>>>> On 07.08.12 at 09:22, "zhenzhong.duan"<zhenzhong.duan@oracle.com>  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@lists.xen.org
http://lists.xen.org/xen-devel