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

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



>>> On 13.08.12 at 09:58, "zhenzhong.duan" <zhenzhong.duan@xxxxxxxxxx> wrote:
> ä 2012-08-10 22:22, Jan Beulich åé:
>> Going back to your original mail, I wonder however why this
>> gets done at all. You said it got there via
>>
>> mtrr_aps_init()
>>   \->  set_mtrr()
>>       \->  mtrr_work_handler()
>>
>> yet this isn't done unconditionally - see the comment before
>> checking mtrr_aps_delayed_init. Can you find out where the
>> obviously necessary call(s) to set_mtrr_aps_delayed_init()
>> come(s) from?
> At bootup stage, set_mtrr_aps_delayed_init is called by 
> native_smp_prepare_cpus.
> mtrr_aps_delayed_init is always set to ture for intel processor in upstream 
> code.

Indeed, and that (in one form or another) has been done
virtually forever in Linux. I wonder why the problem wasn't
noticed (or looked into, if it was noticed) so far.

As it's going to be rather difficult to convince the Linux folks
to change their code (plus this wouldn't help with existing
kernels anyway), we'll need to find a way to improve this in
the hypervisor.

One seemingly orthogonal thing would presumably help quite
a bit on the guest side nevertheless - para-virtualized spin
locks. I have no idea why this is only being done when running
pv, but not for pvhvm. Konrad, Stefano?

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®.