From: Willy Tarreau <w@1wt.eu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andres Freund <andres@anarazel.de>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Linux 4.15-rc6
Date: Wed, 3 Jan 2018 13:57:25 +0100 [thread overview]
Message-ID: <20180103125724.GA2189@1wt.eu> (raw)
In-Reply-To: <CA+55aFze2mpys1e5Yf9ekr4=S2SKFnLfnM4LHU2Y8RFJ5_rugA@mail.gmail.com>
On Tue, Jan 02, 2018 at 01:09:13PM -0800, Linus Torvalds wrote:
> On Tue, Jan 2, 2018 at 12:28 PM, Andres Freund <andres@anarazel.de> wrote:
> >
> > I thought it'd be interesting to run a short benchmark to be able to
> > estimate the impact of the PTI work on postgres workloads (which I work
> > on). On my skylake laptop, a memory resident, OLTP workload with 16
> > connections results in:
>
> Yeah, that's actually pretty much in line with expectations.
>
> Something around 5% performance impact of the isolation is what people
> are looking at.
>
> Obviously it depends on just exactly what you do. Some loads will
> hardly be affected at all, if they just spend all their time in user
> space. And if you do a lot of small system calls, you might see
> double-digit slowdowns.
I can confirm, I've just run some tests on haproxy on a core i7-4790K
and I'm observing a performance loss of ~17%, making the connection
rate go down from 245k/s to 204k/s. It's indeed quite significant for
such use cases, eventhough I think it might reasonably be absorbed by
usual noise in most use cases.
With that said, I think we should start to think about an option to
disable this per process. We could imagine for example a prctl()
requiring CAP_SYS_ADMIN to disable it. This would at least allow
processes started as root to disable it when they consider themselves
irrelevant to this kind of protection (mostly I/O intensive or network
intensive applications).
> > This isn't a complaint, I just thought it might be useful
> > information. If it helps for anything/anybody, I'm happy to run
> > additional benchmarks / provide additional information.
>
> Note that it will depend heavily on the hardware too. Older CPU's
> without PCID will be impacted more by the isolation.
Interesting. This CPU has PCID, so it's possible that older hardware
may indeed be hit a bit more.
Regards,
Willy
next prev parent reply other threads:[~2018-01-03 12:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-31 22:57 Linux 4.15-rc6 Linus Torvalds
2018-01-02 20:28 ` Andres Freund
2018-01-02 21:09 ` Linus Torvalds
2018-01-03 12:57 ` Willy Tarreau [this message]
2018-01-03 21:20 ` Andres Freund
2018-01-04 10:27 ` Willy Tarreau
2018-01-04 11:03 ` 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=20180103125724.GA2189@1wt.eu \
--to=w@1wt.eu \
--cc=andres@anarazel.de \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.