Hi folks, I''ve been using Xen hypervisor for a couple of years. What beats me is, that Windows XP 32-bit performance is quite slow, and there seems to be no improvements with Xen 4.3.0, compared to Xen 4.1.0. I''m using the GPLPV drivers with Windows, I''ve tried the experimental 0.11.0.404 (installation problems), but it''s obvious, the problem isn''t with the GPLPV drivers, as the performance didn''t improve a bit. Yesterday, I upgraded a system that previously had Xen 4.2.0 hypervisor, and a standard Linux kernel 3.7.1 with all Xen-stuff (backends, frontends, etc) activated. I replaced it with a similar Linux kernel 3.10.12 and Xen 4.3.0. I''ve also got another system with about the same setup, though different hardware. In both systems, the Windows XP 32-bit performance is quite below expectations. On the contrary, the performance of Windows XP 64-bit improved considerably, when ported to Xen from an older PC, and it''s really shining. The virtual disks are always LVM-backed, so the issues are not there. Dom0 is using 2 exclusive pinned vcpus in all the machines There''s 2GB of RAM set aside for Dom0 in all setups, which is more than sufficient Dom0 has got weight 6000, and all DomU have got default weight 256 in the scheduler Dom0 normally uses about 10-20% cpu Every DomU is using 2 vcpus, sharing the available vcpus with other machines DomUs mostly have got 1GB of RAM I''ve tried different tweaks, parameter settings, and I don''t know what, and I''d be very grateful for some good advice where to improve the situation. Best regards, Peter
OK, I did comb through the web a bit more, and found something that made a HUGE difference: I added the parameter /patchtpr to the operating system boot line in Windows XP boot.ini Now I''m pleased :-) I wish everybody a nice day, Peter On 2013-09-26 09:55, Peter Milesson wrote:> Hi folks, > > I''ve been using Xen hypervisor for a couple of years. What beats me > is, that Windows XP 32-bit performance is quite slow, and there seems > to be no improvements with Xen 4.3.0, compared to Xen 4.1.0. I''m using > the GPLPV drivers with Windows, I''ve tried the experimental 0.11.0.404 > (installation problems), but it''s obvious, the problem isn''t with the > GPLPV drivers, as the performance didn''t improve a bit. > > Yesterday, I upgraded a system that previously had Xen 4.2.0 > hypervisor, and a standard Linux kernel 3.7.1 with all Xen-stuff > (backends, frontends, etc) activated. I replaced it with a similar > Linux kernel 3.10.12 and Xen 4.3.0. I''ve also got another system with > about the same setup, though different hardware. In both systems, the > Windows XP 32-bit performance is quite below expectations. On the > contrary, the performance of Windows XP 64-bit improved considerably, > when ported to Xen from an older PC, and it''s really shining. > > The virtual disks are always LVM-backed, so the issues are not there. > > Dom0 is using 2 exclusive pinned vcpus in all the machines > There''s 2GB of RAM set aside for Dom0 in all setups, which is more > than sufficient > Dom0 has got weight 6000, and all DomU have got default weight 256 in > the scheduler > Dom0 normally uses about 10-20% cpu > Every DomU is using 2 vcpus, sharing the available vcpus with other > machines > DomUs mostly have got 1GB of RAM > > I''ve tried different tweaks, parameter settings, and I don''t know > what, and I''d be very grateful for some good advice where to improve > the situation. > > Best regards, > > Peter > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users
This thread gives a little more context (for those curious like I was ;-) http://xen.1045712.n5.nabble.com/Windows-domU-opitimization-td2576122.html Seems to affect 2003 before sp2 as well. Thanks! -----Original Message----- From: xen-users-bounces@lists.xen.org [mailto:xen-users-bounces@lists.xen.org] On Behalf Of Peter Milesson Sent: September 26, 2013 7:59 AM To: xen-users Subject: Re: [Xen-users] Slow Windows XP 32-bit OK, I did comb through the web a bit more, and found something that made a HUGE difference: I added the parameter /patchtpr to the operating system boot line in Windows XP boot.ini Now I''m pleased :-) I wish everybody a nice day, Peter On 2013-09-26 09:55, Peter Milesson wrote:> Hi folks, > > I''ve been using Xen hypervisor for a couple of years. What beats me > is, that Windows XP 32-bit performance is quite slow, and there seems > to be no improvements with Xen 4.3.0, compared to Xen 4.1.0. I''m using > the GPLPV drivers with Windows, I''ve tried the experimental 0.11.0.404 > (installation problems), but it''s obvious, the problem isn''t with the > GPLPV drivers, as the performance didn''t improve a bit. > > Yesterday, I upgraded a system that previously had Xen 4.2.0 > hypervisor, and a standard Linux kernel 3.7.1 with all Xen-stuff > (backends, frontends, etc) activated. I replaced it with a similar > Linux kernel 3.10.12 and Xen 4.3.0. I''ve also got another system with > about the same setup, though different hardware. In both systems, the > Windows XP 32-bit performance is quite below expectations. On the > contrary, the performance of Windows XP 64-bit improved considerably, > when ported to Xen from an older PC, and it''s really shining. > > The virtual disks are always LVM-backed, so the issues are not there. > > Dom0 is using 2 exclusive pinned vcpus in all the machines There''s 2GB > of RAM set aside for Dom0 in all setups, which is more than sufficient > Dom0 has got weight 6000, and all DomU have got default weight 256 in > the scheduler > Dom0 normally uses about 10-20% cpu > Every DomU is using 2 vcpus, sharing the available vcpus with other > machines DomUs mostly have got 1GB of RAM > > I''ve tried different tweaks, parameter settings, and I don''t know > what, and I''d be very grateful for some good advice where to improve > the situation. > > Best regards, > > Peter > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
Hi Mitch, It was exactly that post that put me on track (seems to occur in quite a few lists). Now the 32-bit XPs don''t seem slower than their bare metal predecessors. Next thing is to tweak network performance. It seems sufficient so far, but it never hurts to take it to the edge. Best regards, Peter On 2013-09-26 18:07, mitch@bitblock.net wrote:> This thread gives a little more context (for those curious like I was ;-) > http://xen.1045712.n5.nabble.com/Windows-domU-opitimization-td2576122.html > Seems to affect 2003 before sp2 as well. > > Thanks! > > -----Original Message----- > From: xen-users-bounces@lists.xen.org [mailto:xen-users-bounces@lists.xen.org] On Behalf Of Peter Milesson > Sent: September 26, 2013 7:59 AM > To: xen-users > Subject: Re: [Xen-users] Slow Windows XP 32-bit > > OK, I did comb through the web a bit more, and found something that made a HUGE difference: > > I added the parameter /patchtpr to the operating system boot line in Windows XP boot.ini > > Now I''m pleased :-) > > I wish everybody a nice day, > > Peter > > > On 2013-09-26 09:55, Peter Milesson wrote: >> Hi folks, >> >> I''ve been using Xen hypervisor for a couple of years. What beats me >> is, that Windows XP 32-bit performance is quite slow, and there seems >> to be no improvements with Xen 4.3.0, compared to Xen 4.1.0. I''m using >> the GPLPV drivers with Windows, I''ve tried the experimental 0.11.0.404 >> (installation problems), but it''s obvious, the problem isn''t with the >> GPLPV drivers, as the performance didn''t improve a bit. >> >> Yesterday, I upgraded a system that previously had Xen 4.2.0 >> hypervisor, and a standard Linux kernel 3.7.1 with all Xen-stuff >> (backends, frontends, etc) activated. I replaced it with a similar >> Linux kernel 3.10.12 and Xen 4.3.0. I''ve also got another system with >> about the same setup, though different hardware. In both systems, the >> Windows XP 32-bit performance is quite below expectations. On the >> contrary, the performance of Windows XP 64-bit improved considerably, >> when ported to Xen from an older PC, and it''s really shining. >> >> The virtual disks are always LVM-backed, so the issues are not there. >> >> Dom0 is using 2 exclusive pinned vcpus in all the machines There''s 2GB >> of RAM set aside for Dom0 in all setups, which is more than sufficient >> Dom0 has got weight 6000, and all DomU have got default weight 256 in >> the scheduler >> Dom0 normally uses about 10-20% cpu >> Every DomU is using 2 vcpus, sharing the available vcpus with other >> machines DomUs mostly have got 1GB of RAM >> >> I''ve tried different tweaks, parameter settings, and I don''t know >> what, and I''d be very grateful for some good advice where to improve >> the situation. >> >> Best regards, >> >> Peter >> >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xen.org >> http://lists.xen.org/xen-users > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users
Hi folks, Here we go again with the sluggish performance of Windows XP 32-bit under Xen 4.3.0. Up till now, I''ve tested it on AMD hardware, with the parameter /PATCHTPR in the boot.ini file of the Windows XP installation. It works really great, and Windows XP performance is relly outstanding, almost better than on bare metal. When I use the parameter /PATCHTPR in the boot.ini of a Windows XP installation under Intel hardware, it crashes utterly, almost immediately during boot. What I could se from the little information that''s available, the /PATCHTPR parameter only applies to Windows XP 32-bit, and Windows 2000 running under Xen on AMD hardware. The Intel Xen installation is almost identical to the one I described in my first post a few days ago. It''s really annoying and frustrating. I would be very grateful for some good advice, how to speed up Windows XP 32-bit under Xen in Intel hardware. Best regards, Peter
> Hi folks, > > Here we go again with the sluggish performance of Windows XP 32-bit > under Xen 4.3.0. Up till now, I''ve tested it on AMD hardware, with the > parameter /PATCHTPR in the boot.ini file of the Windows XP installation. > It works really great, and Windows XP performance is relly outstanding, > almost better than on bare metal. > > When I use the parameter /PATCHTPR in the boot.ini of a Windows XP > installation under Intel hardware, it crashes utterly, almost > immediately during boot. What I could se from the little information > that''s available, the /PATCHTPR parameter only applies to Windows XP > 32-bit, and Windows 2000 running under Xen on AMD hardware. > > The Intel Xen installation is almost identical to the one I described in > my first post a few days ago. It''s really annoying and frustrating. > > I would be very grateful for some good advice, how to speed up Windows > XP 32-bit under Xen in Intel hardware. >So it''s definitely just as slow under Intel? For some reason I thought there was some inherent speedup available for Intel these days that didn''t need any TPR patching. The problem is that 2000, XP, and 2003 (when older than SP2) access the Task PRiority register lots, and doing so is very slow. The patchtpr option modifies the windows kernel to try and find another way to emulate this without requiring an emulation by Xen. First it checks the CPUID to see if the cpu supports a way to access the TPR register via CR8. AMD allows this in 32 bit mode via a MOVE CR0 instruction, prefixed with a LOCK. Intel has no such feature. If that option isn''t available, it tries to map the vlapic to memory so it can tinker with TPR that way. If all else fails, it caches any writes to the TPR register and only actually writes when it would change the value of TPR. So you get a huge speedup for TPR reads, and for any write to TPR that results in the same value being written. It''s not ideal but it does make a big difference. I need to know which of the last two is being selected on your system. I suspect it will be the method that maps the vlapic. Can you install the debug version of the drivers, then send me the output of /var/log/xen/qemu-<domu name>.log? There should be some info logged in there about what patching is being done. There is a chance that this logging is done too early and you''ll need to attach a debugger to capture that output, if so let me know and I should be able to give you a version that patches later. If nothing else, I should be able to modify gplpv so that you can select the last option and get some improvement, once I figure out what is going on. James
On 2013-09-27 13:42, James Harper wrote:>> Hi folks, >> >> Here we go again with the sluggish performance of Windows XP 32-bit >> under Xen 4.3.0. Up till now, I''ve tested it on AMD hardware, with the >> parameter /PATCHTPR in the boot.ini file of the Windows XP installation. >> It works really great, and Windows XP performance is relly outstanding, >> almost better than on bare metal. >> >> When I use the parameter /PATCHTPR in the boot.ini of a Windows XP >> installation under Intel hardware, it crashes utterly, almost >> immediately during boot. What I could se from the little information >> that''s available, the /PATCHTPR parameter only applies to Windows XP >> 32-bit, and Windows 2000 running under Xen on AMD hardware. >> >> The Intel Xen installation is almost identical to the one I described in >> my first post a few days ago. It''s really annoying and frustrating. >> >> I would be very grateful for some good advice, how to speed up Windows >> XP 32-bit under Xen in Intel hardware. >> > So it''s definitely just as slow under Intel? For some reason I thought there was some inherent speedup available for Intel these days that didn''t need any TPR patching. > > The problem is that 2000, XP, and 2003 (when older than SP2) access the Task PRiority register lots, and doing so is very slow. The patchtpr option modifies the windows kernel to try and find another way to emulate this without requiring an emulation by Xen. > > First it checks the CPUID to see if the cpu supports a way to access the TPR register via CR8. AMD allows this in 32 bit mode via a MOVE CR0 instruction, prefixed with a LOCK. Intel has no such feature. > > If that option isn''t available, it tries to map the vlapic to memory so it can tinker with TPR that way. > > If all else fails, it caches any writes to the TPR register and only actually writes when it would change the value of TPR. So you get a huge speedup for TPR reads, and for any write to TPR that results in the same value being written. It''s not ideal but it does make a big difference. > > I need to know which of the last two is being selected on your system. I suspect it will be the method that maps the vlapic. Can you install the debug version of the drivers, then send me the output of /var/log/xen/qemu-<domu name>.log? There should be some info logged in there about what patching is being done. There is a chance that this logging is done too early and you''ll need to attach a debugger to capture that output, if so let me know and I should be able to give you a version that patches later. > > If nothing else, I should be able to modify gplpv so that you can select the last option and get some improvement, once I figure out what is going on. > > James > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-usersHi James, I get exclusive access to the server tomorrow, and on Sunday, so perhaps I''ll succeed to supply the log then. The Windows domU not even starts when I use the /PATCHTPR parameter, crashes immediately after the short wait for F8. The GPLPV drivers used are 0.11.0.357. I tried to install the latest experimental drivers, but the installer waited for something indefinitely. Otherwise, the Windows XP performance is horrible, and about the same on the homebuilt AMD platform (6-core FX6100, AMD 970A chipsset, 12GB RAM) without PATCHTPR and the Dell server Intel platform (4-core Intel Xeon E31220, Intel C200 chipsset, 12GB RAM). I really appreciate your input. I wish you a nice weekend, Peter
On 2013-09-27 15:44, Peter Milesson wrote:> > On 2013-09-27 13:42, James Harper wrote: >>> Hi folks, >>> >>> Here we go again with the sluggish performance of Windows XP 32-bit >>> under Xen 4.3.0. Up till now, I''ve tested it on AMD hardware, with the >>> parameter /PATCHTPR in the boot.ini file of the Windows XP >>> installation. >>> It works really great, and Windows XP performance is relly outstanding, >>> almost better than on bare metal. >>> >>> When I use the parameter /PATCHTPR in the boot.ini of a Windows XP >>> installation under Intel hardware, it crashes utterly, almost >>> immediately during boot. What I could se from the little information >>> that''s available, the /PATCHTPR parameter only applies to Windows XP >>> 32-bit, and Windows 2000 running under Xen on AMD hardware. >>> >>> The Intel Xen installation is almost identical to the one I >>> described in >>> my first post a few days ago. It''s really annoying and frustrating. >>> >>> I would be very grateful for some good advice, how to speed up Windows >>> XP 32-bit under Xen in Intel hardware. >>> >> So it''s definitely just as slow under Intel? For some reason I >> thought there was some inherent speedup available for Intel these >> days that didn''t need any TPR patching. >> >> The problem is that 2000, XP, and 2003 (when older than SP2) access >> the Task PRiority register lots, and doing so is very slow. The >> patchtpr option modifies the windows kernel to try and find another >> way to emulate this without requiring an emulation by Xen. >> >> First it checks the CPUID to see if the cpu supports a way to access >> the TPR register via CR8. AMD allows this in 32 bit mode via a MOVE >> CR0 instruction, prefixed with a LOCK. Intel has no such feature. >> >> If that option isn''t available, it tries to map the vlapic to memory >> so it can tinker with TPR that way. >> >> If all else fails, it caches any writes to the TPR register and only >> actually writes when it would change the value of TPR. So you get a >> huge speedup for TPR reads, and for any write to TPR that results in >> the same value being written. It''s not ideal but it does make a big >> difference. >> >> I need to know which of the last two is being selected on your >> system. I suspect it will be the method that maps the vlapic. Can you >> install the debug version of the drivers, then send me the output of >> /var/log/xen/qemu-<domu name>.log? There should be some info logged >> in there about what patching is being done. There is a chance that >> this logging is done too early and you''ll need to attach a debugger >> to capture that output, if so let me know and I should be able to >> give you a version that patches later. >> >> If nothing else, I should be able to modify gplpv so that you can >> select the last option and get some improvement, once I figure out >> what is going on. >> >> James >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xen.org >> http://lists.xen.org/xen-users > Hi James, > > I get exclusive access to the server tomorrow, and on Sunday, so > perhaps I''ll succeed to supply the log then. > > The Windows domU not even starts when I use the /PATCHTPR parameter, > crashes immediately after the short wait for F8. The GPLPV drivers > used are 0.11.0.357. I tried to install the latest experimental > drivers, but the installer waited for something indefinitely. > Otherwise, the Windows XP performance is horrible, and about the same > on the homebuilt AMD platform (6-core FX6100, AMD 970A chipsset, 12GB > RAM) without PATCHTPR and the Dell server Intel platform (4-core Intel > Xeon E31220, Intel C200 chipsset, 12GB RAM). > > I really appreciate your input. > > I wish you a nice weekend, > > Peter > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-usersHi James, The log file is empty. When I installed the debug version 0.11.0.404 it changed behavior a bit. With previous non-debug version of the GPLPV drivers, the dead domu remained in the list, and when destroying it, there was an information message, that it is already exited. With the latest debug drivers, the domu dies immediately after the initial wait for F8, and does not show up in the task list any more. Hope it''s information enough for you. For me it would be quite tricky to go deeper, with debuggers and that stuff. Best regards, Peter