[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH RFC V11 15/18] kvm : Paravirtual ticketlocks support for linux guests running on KVM hypervisor
- To: Ingo Molnar <mingo@xxxxxxxxxx>
- From: Raghavendra K T <raghavendra.kt@xxxxxxxxxxxxxxxxxx>
- Date: Fri, 02 Aug 2013 15:14:10 +0530
- Cc: jeremy@xxxxxxxx, gregkh@xxxxxxx, Gleb Natapov <gleb@xxxxxxxxxx>, linux-doc@xxxxxxxxxxxxxxx, peterz@xxxxxxxxxxxxx, drjones@xxxxxxxxxx, virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx, andi@xxxxxxxxxxxxxx, hpa@xxxxxxxxx, stefano.stabellini@xxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, kvm@xxxxxxxxxxxxxxx, x86@xxxxxxxxxx, agraf@xxxxxxx, mingo@xxxxxxxxxx, habanero@xxxxxxxxxxxxxxxxxx, ouyang@xxxxxxxxxxx, avi.kivity@xxxxxxxxx, tglx@xxxxxxxxxxxxx, chegu_vinod@xxxxxx, mtosatti@xxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, srivatsa.vaddagiri@xxxxxxxxx, attilio.rao@xxxxxxxxxx, pbonzini@xxxxxxxxxx, torvalds@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Fri, 02 Aug 2013 09:38:32 +0000
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
On 08/02/2013 02:53 PM, Ingo Molnar wrote:
* Raghavendra K T <raghavendra.kt@xxxxxxxxxxxxxxxxxx> wrote:
On 08/01/2013 02:34 PM, Raghavendra K T wrote:
On 08/01/2013 01:15 PM, Gleb Natapov wrote:
Shall I consider this as an ack for kvm part?
For everything except 18/18. For that I still want to see numbers. But
18/18 is pretty independent from the reset of the series so it should
not stop the reset from going in.
Yes. agreed.
I am going to evaluate patch 18 separately and come with results for
that. Now we can consider only 1-17 patches.
Gleb,
32 core machine with HT off 32 vcpu guests.
base = 3.11-rc + patch 1 -17 pvspinlock_v11
patched = base + patch 18
+-----------+-----------+-----------+------------+-----------+
dbench (Throughput in MB/sec higher is better)
+-----------+-----------+-----------+------------+-----------+
base stdev patched stdev %improvement
+-----------+-----------+-----------+------------+-----------+
1x 14584.3800 146.9074 14705.1000 163.1060 0.82773
2x 1713.7300 32.8750 1717.3200 45.5979 0.20948
3x 967.8212 42.0257 971.8855 18.8532 0.41994
4x 685.2764 25.7150 694.5881 8.3907 1.35882
+-----------+-----------+-----------+------------+-----------+
Please list stddev in percentage as well ...
Sure. will do this from next time.
a blind stab gave me these figures:
base stdev patched stdev %improvement
3x 967.8212 4.3% 971.8855 1.8% 0.4
That makes the improvement an order of magnitude smaller than the noise of
the measurement ... i.e. totally inconclusive.
Okay. agreed.
I always had seen the positive effect of the patch since it uses ple
handler heuristics, and thus avoiding the directed yield to vcpu's in
halt handler. But the current results clearly does not conclude
anything favoring that. :(
So please drop patch 18 for now.
Also please cut the excessive decimal points: with 2-4% noise what point
is there in 5 decimal point results??
Yes.
Ingo, do you think now the patch series (patch 1 to 17) are in good
shape? or please let me know if you have any concerns to be
addressed.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
