From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Bruce Rogers" Subject: Re: [PATCH] respin of mprotect performance patch Date: Tue, 22 Jan 2008 14:51:00 -0700 Message-ID: <47960334.092E.0048.1@novell.com> References: <47826C1C.5C6B.0048.1@novell.com> <4789207C.5C6B.0048.1@novell.com> <20080121104159.64454b72@bree.surriel.com> <20080122135534.1225627e@cuia.boston.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20080122135534.1225627e@cuia.boston.redhat.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Rik van Riel Cc: dshaks@redhat.com, bmarson@redhat.com, xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Your results are quite different from what I've seen. But then again I've = been doing slightly different scaling tests, and of course the hardware is = different. In the original problem report we received from SAP, the # of cpus was = varied while running their test which runs 3 cpuload streams on each cpu. = I've continued down that path since it shows a steady degradation as more = cpus are added. I've not played with varying the number of cpuload = streams in my testing. Other than that, it sounds like we are running the same SAP test (cpu_load.= sh). Here's what I've seen (numbers are the throughput per cpu, test assigns 3 = streams per cpu, test was run in Dom0, as it was in the SAP problem = report): #cpus native with patch without patch 1 9434 8264 6095 2 9884 8227 4530 3 9790 8008 2962 4 9392 7531 1801 8 6507 5870 669 So as you can see the performance degradation I am seeing is quite marked, = and the benefit of the patch quite consistent and obviously beneficial. The machine I used is a 8 processor (4 dual core AMD Opteron 8218 CPUs, = ea. w/ 1MB L2 Cache) HP Proliant Server with 16GB memory. I do wish I had been able to do testing with more than 1 machine; perhaps = that would have provided better insights into the performance problem. = Out lab is in a state of flux right now as we're moving floors and I hence = probably won't be able to do a comparative run on other hardware very = soon. I believe SAP is doing some broad based testing of their own which may = help identify how much the hardware has to do with the performance of this = test. What results do you get with native (non-smp) on that same hardware? Have = you done runs on other hardware and seen consistent results? - Bruce >>> On 1/22/2008 at 11:55 AM, in message <20080122135534.1225627e@cuia.boston.redhat.com>, Rik van Riel wrote: > On Mon, 21 Jan 2008 10:41:59 -0500 > Rik van Riel wrote: >=20 >> I tested a quick backport of these patches to XEN 3.1.2 and >> kernel 2.6.18. >>=20 >> Unfortunately, performance and scalability do not seem to >> have improved with these patches, >=20 > OK, it turned out the guys with the SAP mprotect benchmark program > made the mistake of only upgrading the dom0 kernel and not the guest. >=20 > With both dom0 and guest, mprotect performance has improved slightly > on our dual cpu, dual core (4 cores total) Intel x86-64 test system: >=20 > CPULOAD WITH =20 > STREAMS PATCH STANDARD > 1 13108.77 11188.68 > 2 13135.63 11146.06 > 3 10522.82 9910.10 > 4 8622.47 9399.66 > 6 6571.49 7078.12 > 8 5141.23 5389.15 > 10 4514.37 4372.87 > 12 4226.79 3802.98 >=20 > So we have about a 10-15% performance improvement at some numbers of > streams, and a performance decrease at some other numbers of streams. > Over-all performance impact of the patch seems to be about even :( >=20 > I wonder if this is just an artifact of the system we tested this on, > or if it can be seen across multiple systems. >=20 > Bruce, what kinds of systems have you tested the patch on and what > kind of performance numbers are you seeing?