stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Feedback on 4.9 performance after PTI fixes
Date: Sun, 7 Jan 2018 11:18:56 +0100	[thread overview]
Message-ID: <20180107101856.GA9590@1wt.eu> (raw)

Hi,

I managed to take a bit of time to run some more tests on PTI both
native and hosted in KVM, on stable versions built with
CONFIG_PAGE_TABLE_ISOLATION=y. Here it's 4.9.75, used both on the
host and the VM. I could compare pti=on/off both in the host and the
VM. A single CPU was exposed in the VM.

It was running on my laptop (core i7 3320M at 2.6 GHz, 3.3 GHz single
core turbo).

The test was run on haproxy's ability to forward connections. The
results are below :

   Host  |  Guest  | conn/s  | ratio_to_host |  ratio_to_VM | Notes
---------+---------+---------+---------------+--------------+----------------
 pti=off |   -     |  27400  |     100.0%    |      -       | host reference
 pti=off | pti=off |  24200  |      88.3%    |    100.0%    | VM reference 
 pti=off | pti=on  |  13300  |      48.5%    |     55.0%    |
 pti=on  |   -     |  23800  |      86.9%    |      -	    | protected host
 pti=on  | pti=off |  23100  |      84.3%    |     95.5%    |
 pti=on  | pti=on  |  13300  |      48.5%    |     55.0%    |

The ratio_to_host column shows the performance relative to the host
with pti=off. The ratio_to_VM column shows the performance relative to
the VM running with pti=off in a host also having pti=off (ie:
performance before upgrading the systems).

On this test we see a few things :
  - the performance impact on the native host is around 13%

  - the highest performance impact on VMs comes from having PTI on the
    guest kernel (-45%). At this point it makes no difference whether
    the host kernel has it or not.

  - the host kernel's protection has a very limited impact on the guest
    system's performance (-4.5%), which is probably nice for some cloud
    users who might want to take the risk of turning the protection off
    on their VMs.

The impact inside VMs is quite big but it's not where we usuall install
processes sensitive to syscall performance. I could find an even higher
impact on a packet generation program dropping from 2.5 Mpps to 600kpps
in the VM after the fix, but it doesn't make much sense to do this in
VMs so I don't really care.

I have not yet tried the retpoline patches.

Regards,
Willy

             reply	other threads:[~2018-01-07 10:18 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-07 10:18 Willy Tarreau [this message]
2018-01-08 17:07 ` Feedback on 4.9 performance after PTI fixes Yves-Alexis Perez
2018-01-08 17:21   ` Yves-Alexis Perez
2018-01-08 18:26   ` Willy Tarreau
2018-01-08 20:26     ` Yves-Alexis Perez
2018-01-08 20:39       ` Willy Tarreau
2018-01-08 22:45         ` Pavlos Parissis
2018-01-08 17:26 ` David Laight
2018-01-09  7:09 ` Willy Tarreau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180107101856.GA9590@1wt.eu \
    --to=w@1wt.eu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).