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@xxxxxxxxxxxxxxxxxxxxxx>, Rik van Riel
<riel@xxxxxxxxxx> wrote:
> On Mon, 21 Jan 2008 10:41:59 -0500
> Rik van Riel <riel@xxxxxxxxxx> 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?
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home