Re: [Xen-devel] [PATCH v13 10/11] pvqspinlock, x86: Enable PV qspinlock for KVM

[Thomas Gleixner <tglx@xxxxxxxxxxxxx>]

On Wed, 29 Oct 2014, Waiman Long wrote:
>                 AIM7 XFS Disk Test (no overcommit)
>   kernel                 JPM    Real Time   Sys Time    Usr Time
>   -----                  ---    ---------   --------    --------
>   PV ticketlock         2542373    7.08       98.95       5.44
>   PV qspinlock          2549575    7.06       98.63       5.40
>   unfairlock          2616279    6.91       97.05       5.42
> 
>                 AIM7 XFS Disk Test (200% overcommit)
>   kernel                 JPM    Real Time   Sys Time    Usr Time
>   -----                  ---    ---------   --------    --------
>   PV ticketlock         644468    27.93      415.22       6.33
>   PV qspinlock          645624    27.88      419.84       0.39

That number is made up by what? ----------------------------^^^^

>   unfairlock          695518    25.88      377.40       4.09
> 
>                 AIM7 EXT4 Disk Test (no overcommit)
>   kernel                 JPM    Real Time   Sys Time    Usr Time
>   -----                  ---    ---------   --------    --------
>   PV ticketlock         1995565    9.02      103.67       5.76
>   PV qspinlock          2011173    8.95      102.15       5.40
>   unfairlock          2066590    8.71       98.13       5.46
> 
>                 AIM7 EXT4 Disk Test (200% overcommit)
>   kernel                 JPM    Real Time   Sys Time    Usr Time
>   -----                  ---    ---------   --------    --------
>   PV ticketlock         478341    37.63      495.81      30.78
>   PV qspinlock          474058    37.97      475.74      30.95
>   unfairlock          560224    32.13      398.43      26.27
> 
> For the AIM7 disk workload, both PV ticketlock and qspinlock have
> about the same performance. The unfairlock performs slightly better
> than the PV lock.

Slightly?

Taking the PV locks, which are basically the same for the existing
ticket locks and your new fangled qlocks as a reference then the so
called 'unfair locks' which are just the native locks w/o the PV
nonsense are fundamentally better up to a whopping 18% in the
ext4/200% overcommit case. See below.
 
>                 EBIZZY-m Test (no overcommit)
>   kernel                Rec/s   Real Time   Sys Time    Usr Time
>   -----                 -----   ---------   --------    --------
>   PV ticketlock         3255      10.00       60.65       3.62
>   PV qspinlock          3318      10.00       54.27       3.60
>   unfairlock          2833      10.00       26.66       3.09
> 
>                 EBIZZY-m Test (200% overcommit)
>   kernel                Rec/s   Real Time   Sys Time    Usr Time
>   -----                 -----   ---------   --------    --------
>   PV ticketlock          841      10.00       71.03       2.37
>   PV qspinlock           834      10.00       68.27       2.39
>   unfairlock           865      10.00       27.08       1.51
> 
>   futextest (no overcommit)
>   kernel               kops/s
>   -----                ------
>   PV ticketlock        11523
>   PV qspinlock         12328
>   unfairlock          9478
> 
>   futextest (200% overcommit)
>   kernel               kops/s
>   -----                ------
>   PV ticketlock         7276
>   PV qspinlock          7095
>   unfairlock          5614
> 
> The ebizzy and futextest have much higher spinlock contention than
> the AIM7 disk workload. In this case, the unfairlock performs worse
> than both the PV ticketlock and qspinlock. The performance of the 2
> PV locks are comparable.

While I can see that the PV lock stuff performs 13% better for the
ebizzy no overcommit case, what about the very interresting numbers
for the same test with 200% overcommit?

The regular lock has a slightly better performance, but significantly
less sys/usr time. How do you explain that?

'Lies, damned lies and statistics' comes to my mind.

Thanks,

        tglx

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel