Re: [PATCH] respin of mprotect performance patch

["Bruce Rogers" <BROGERS@novell.com>]

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
<intervening cpu counts not test, trend seemed obvious>
    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
<riel@redhat.com> wrote:
> On Mon, 21 Jan 2008 10:41:59 -0500
> Rik van Riel <riel@redhat.com> wrote:
> 
>> I tested a quick backport of these patches to XEN 3.1.2 and
>> kernel 2.6.18.
>> 
>> Unfortunately, performance and scalability do not seem to
>> have improved with these patches,
> 
> 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.
> 
> With both dom0 and guest, mprotect performance has improved slightly
> on our dual cpu, dual core (4 cores total) Intel x86-64 test system:
> 
> CPULOAD    WITH     
> 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
> 
> 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 :(
> 
> I wonder if this is just an artifact of the system we tested this on,
> or if it can be seen across multiple systems.
> 
> Bruce, what kinds of systems have you tested the patch on and what
> kind of performance numbers are you seeing?