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

Re: [Xen-devel] [PATCH] Don't track all memory when enabling log dirty to track vram

>>> On 17.02.14 at 13:23, George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
> On 02/17/2014 10:18 AM, Jan Beulich wrote:
>> And second, I have been fighting with finding both conditions
>> and (eventually) the root cause of a severe performance
>> regression (compared to 4.3.x) I'm observing on an EPT+IOMMU
>> system. This became _much_ worse after adding in the patch here
>> (while in fact I had hoped it might help with the originally observed
>> degradation): X startup fails due to timing out, and booting the
>> guest now takes about 20 minutes). I didn't find the root cause of
>> this yet, but meanwhile I know that
>> - the same isn't observable on SVM
>> - there's no problem when forcing the domain to use shadow
>>    mode
>> - there's no need for any device to actually be assigned to the
>>    guest
>> - the regression is very likely purely graphics related (based on
>>    the observation that when running something that regularly but
>>    not heavily updates the screen with X up, the guest consumes a
>>    full CPU's worth of processing power, yet when that updating
>>    doesn't happen, CPU consumption goes down, and it goes further
>>    down when shutting down X altogether - at least as log as the
>>    patch here doesn't get involved).
>> This I'm observing on a Westmere box (and I didn't notice it earlier
>> because that's one of those where due to a chipset erratum the
>> IOMMU gets turned off by default), so it's possible that this can't
>> be seen on more modern hardware. I'll hopefully find time today to
>> check this on the one newer (Sandy Bridge) box I have.
> So you're saying that the slowdown happens if you have EPT+IOMMU, but 
> *not* if you have EPT alone (IOMMU disabled), or shadow + IOMMU?
> I have an issue I haven't had time to look into where windows installs 
> are sometimes terribly slow on my Nehalem box; but it seems to be only 
> with qemu-xen, not qemu-traditional.  I haven't tried with shadow.

Sorry I forgot to mention this - I too suspected the qemu version
update to be one possible reason, but I'm seeing the same behavior
with qemu-trad.


Xen-devel mailing list



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