Re: [Xen-devel] xen-unstable, winxp32 very poor performance on AMD FX-8150, I bisected and changeset is 24770:7f79475d3de7

[Andres Lagar-Cavilla <andreslc@xxxxxxxxxxxxxx>]

I unfortunately don't have AMD hardware to test with. On our regular win7 
EPT-based workloads we've seen no noticeable degradations.

The answer to this one obviously lies in profiling the right sw/hw combo.

Andres
On Jan 18, 2013, at 9:22 AM, George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:

> On 17/01/13 20:57, Pasi Kärkkäinen wrote:
>> Hello,
>> 
>> George: What do you think, should we add this bug to the Xen 4.3 status 
>> email for tracking it?
>> It's a serious HVM/winxp performance regression on AMD..
> 
> Hey Pasi -- thanks for bringing this thread to my attention.  I had noticed a 
> performance impact on AMD boxen myself, but investigating it had kind of 
> gotten buried in more urgent tasks.  Yes, I think we should track it.  I'll 
> put it on the list.
> 
> -George
> 
>> 
>> -- Pasi
>> 
>> On Sat, Jan 12, 2013 at 04:25:47PM +0100, Peter Maloney wrote:
>>> On 11/22/2012 07:54 PM, Peter Maloney wrote:
>>>> On 11/13/2012 02:17 PM, Peter Maloney wrote:
>>>>> On 2012-11-01 18:28, Andres Lagar-Cavilla wrote:
>>>>>> On Nov 1, 2012, at 1:00 PM, Tim Deegan <tim@xxxxxxx> wrote:
>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> At 14:59 +0100 on 22 Oct (1350917960), Tim Deegan wrote:
>>>>>>>> At 19:21 +0200 on 20 Oct (1350760876), Peter Maloney wrote:
>>>>>>>>> The change was 8 months ago
>>>>>>>>> 
>>>>>>>>> changeset:   24770:7f79475d3de7
>>>>>>>>> user:        Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx>
>>>>>>>>> date:        Fri Feb 10 16:07:07 2012 +0000
>>>>>>>>> summary:     x86/mm: Make p2m lookups fully synchronized wrt 
>>>>>>>>> modifications
>>>>>>> [...]
>>>>>> Not any immediate ideas without profiling.
>>>>>> 
>>>>>> However, most callers of hvmemul_do_io pass a stub zero ram_gpa address. 
>>>>>> We might be madly hitting the p2m locks for no reason there.
>>>>>> 
>>>>>> How about the following patch, Peter, Tim?
>>>> I tried the patch applied to xen-unstable 4.2.0-branched
>>>> 528f0708b6db+ 4.2.0-branched
>>>> 
>>>> It seemed the same. It was extremely slow with 7 vcpus, and with 2 vcpus
>>>> it was slow, but fast enough that I could bother to log in and out
>>>> during the test.
>>>> 
>>>> Attached are logs generated with this command (using xm instead of xl):
>>>> for i in {1..30}; do xm debug-keys d; xm dmesg -c; done >> nameoflog
>>>> 
>>>> xenxp_xm_dmesg_-c_7cpus_idle.log
>>>> xenxp_xm_dmesg_-c_7cpus_logintooslow.log
>>>> xenxp_xm_dmesg_-c_7cpus_shutdown.log
>>>> xenxp_xm_dmesg_-c_duringlogin.log
>>>> xenxp_xm_dmesg_-c_idling_login_screen.log
>>>> 
>>>> Also there is xenxp_dmesg.log which is output from hitting alt+sysrq+w
>>>> and p in case it's relevant.
>>>> 
>>>> BTW this time I am testing with kernel 3.6.7
>>>> 
>>> 
>>> I also tested 4.2.1 now, and it has the same problem. And after using it
>>> for a while with windows 8 (playing games), I get the general feel that
>>> it is laggier than with 4.1.3. And now I'm using 4.1.4 which is fast
>>> like 4.1.3.
>>> 
>>> So any ideas on how to fix this or gather more useful information?
>>> 
>>> 
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@xxxxxxxxxxxxx
>>> http://lists.xen.org/xen-devel
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel