heads up: Fix for intel hardware bug will lead to performance regressions

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
Subject: heads up: Fix for intel hardware bug will lead to performance regressions
Date: 2018-01-02 22:23:54
Message-ID: 20180102222354.qikjmf7dvnjgbkxe@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Upcoming versions of the linux kernel (and apparently also windows and
others), will include new feature that apparently has been implemented
with haste to work around an intel hardware bug.

https://lwn.net/SubscriberLink/741878/eaff7b24627c41a2/

The fix, split userland / kernel pagetables, is going to be merged in
the next version of the linux kernel and is being backported to older
point releases. The backports of a complex invasive new feature signals
that this concerns a significant issue.

There's plenty speculation about details about what exactly the
vulnerability is. Don't want to go into that here.

The fix will unfortunately cause performance regressions. Depending on
the hardware version and kernel version (will not be backported for
every version) hardware features (PCID / ASID) will be used to reduce
the impact.

pti is the workaroud, page table isolation, which can be
enabled/disabled via boot parameters. nopcid disables the use of the
hardware feature that reduces the impact of workaround. PCID support

readonly pgbench (tpch-like), 16 clients, i7-6820HQ CPU (skylake):

pti=off:
tps = 236629.778328

pti=on:
tps = 220791.228297 (~0.93x)

pti=on, nopcid:
tps = 198959.801459 (~0.84x)

To get closer to the worst case, I've also measured:

pgbench SELECT 1, 16 clients, i7-6820HQ CPU (skylake):

pti=off:
tps = 420490.162391

pti=on:
tps = 350746.065039 (~0.83x)

pti=on, nopcid:
tps = 324269.903152 (~0.77x)

Note that real-world scenarios probably will see somewhat smaller
impact, as this was measured over a loopback unix sockets which'll have
smaller overhead itself than proper TCP sockets + actual network.

The rumor mill has it that details about the vulnerability will be
un-embargoed in the next few days.

Greetings,

Andres Freund

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2018-01-02 22:23:58 Re: [HACKERS] SQL/JSON in PostgreSQL
Previous Message Alexander Korotkov 2018-01-02 22:21:34 Re: [Patch] Checksums for SLRU files