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

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



On Mon, Apr 29, 2013 at 6:55 PM, Konrad Rzeszutek Wilk
<konrad.wilk@xxxxxxxxxx> wrote:
> On Thu, Aug 30, 2012 at 10:03:12AM +0100, Tim Deegan wrote:
>> At 13:36 +0800 on 29 Aug (1346247391), zhenzhong.duan wrote:
>> >
>> >
>> > ??? 2012-08-13 17:29, Jan Beulich ??????:
>> > >>>>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.
>> > Hi Jan, Tim
>> > Is this issue improvable from xen side?
>>
>> Probably; we're looking into the best way to address it.
>>
>> Tim.
>
> Ping? Was there any progress on this? Thanks

Does this need to be added to our tracking list?

 -George

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