x86 patch ping

x86 patch ping

[Jan Beulich]

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.

Thanks, Jan


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

Re: x86 patch ping

[Andrew Cooper]

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 <andrew.cooper3@citrix.com>

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

Re: x86 patch ping

[Jan Beulich]

>>> On 08.04.16 at 14:18, <andrew.cooper3@citrix.com> 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: x86 patch ping

[Andrew Cooper]

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: x86 patch ping

[Jan Beulich]

>>> Andrew Cooper <andrew.cooper3@citrix.com> 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