Re: [Xen-devel] x86 patch ping
>>> Andrew Cooper 04/15/16 7:12 PM >>> >On 08/04/16 13:10, Jan Beulich wrote: >> http://lists.xen.org/archives/html/xen-devel/2016-03/msg02167.html >> (with the 1st patch having gone in already) > >Apologies for the delay on this. I now have results in. > >The 64bit performance hit is within the noise (as expected) but sadly, Thanks - at least something good here. >the performance impact of v3 on 32bit guests is even worse than previous >rounds. > >From lmbench: > >mmap() has an 85% latency hit. >pagefaults (on /local/scratch) gets a 78% hit. >pipe latency gets a 58% hit. >process fork()/exit() gets a 47% hit. > >In each of these cases, that is about 20% worse that previous measurements. I have to admit that I have a _very_ hard time seeing why the most recent adjustments would have made things worse. >As it currently stands, we really can't justify taking the fix in its >current form. Which raises the question of alternatives. Fact is that we're having a problem to solve, and no solution getting things back to architecturally correct behavior other than this one. Which makes me wonder whether we shouldn't take the change irrespective of its performance effect, provided that performance goes back up if people use "no-smep" and/or "no-smap" as appropriate. (Specifying to use these options to restore architecturally correct behavior is, imo, not an acceptable thing to do, but suggesting their use to get performance back for those who value security less than performance imo is an option.) Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] x86 patch ping
On 08/04/16 13:10, Jan Beulich wrote: > http://lists.xen.org/archives/html/xen-devel/2016-03/msg02167.html > (with the 1st patch having gone in already) Apologies for the delay on this. I now have results in. The 64bit performance hit is within the noise (as expected) but sadly, the performance impact of v3 on 32bit guests is even worse than previous rounds. From lmbench: mmap() has an 85% latency hit. pagefaults (on /local/scratch) gets a 78% hit. pipe latency gets a 58% hit. process fork()/exit() gets a 47% hit. In each of these cases, that is about 20% worse that previous measurements. As it currently stands, we really can't justify taking the fix in its current form. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] x86 patch ping
>>> On 08.04.16 at 14:18, wrote: > The SMEP/SMAP series is still very concerning. I need to follow up on > the performance testing, but it currently looks like no real improvement > on the 40-70% performance hit for 32bit PV guests. Well, we didn't really expect much of a change for 32-bit guests. The more important question is whether at least the 64-bit guest picture improved. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] x86 patch ping
On 08/04/16 13:10, Jan Beulich wrote:
> Andrew,
>
> could I please get acks or otherwise on
>
> http://lists.xen.org/archives/html/xen-devel/2016-03/msg01469.html
>
> http://lists.xen.org/archives/html/xen-devel/2016-03/msg02167.html
> (with the 1st patch having gone in already)
>
> http://lists.xen.org/archives/html/xen-devel/2016-04/msg00040.html
>
> There are also
> http://lists.xen.org/archives/html/xen-devel/2016-03/msg03746.html
> http://lists.xen.org/archives/html/xen-devel/2016-03/msg03747.html
> but I guess I'll put them in without further acks, considering they
> are simply ports from Linux.
These last 3 links ("x86/vMSI-X: fix qword write" and the two from
linux) are straightforward.
Acked-by: Andrew Cooper
The first I will need to do a closer review of.
The SMEP/SMAP series is still very concerning. I need to follow up on
the performance testing, but it currently looks like no real improvement
on the 40-70% performance hit for 32bit PV guests.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
