On 2018-01-08 14:38:20 +1300, Thomas Munro wrote:
> Just an idea, not sure if it's worth looking into; maybe we already
> spend enough time filling those buffers that a 50% syscall markup
> won't hurt.
Yea, I suspect that won't make a huge difference - copying an 8kb buffer
is typically a lot more
On Mon, Jan 8, 2018 at 1:32 PM, Thomas Munro
wrote:
> Also pgarch.c, syncrep.c, walsender.c and walreceiver.c use
> PostmasterIsAlive() every time through their loops[1] generating extra
> syscalls, one instance of which has caused complaints before[1] on a
> system where the syscall was expensive
On Mon, Jan 8, 2018 at 2:38 PM, Thomas Munro
wrote:
> On Fri, Jan 5, 2018 at 6:28 AM, Robert Haas wrote:
>> On Tue, Jan 2, 2018 at 5:23 PM, Andres Freund wrote:
>>> Note that real-world scenarios probably will see somewhat smaller
>>> impact, as this was measured over a loopback unix sockets whi
On Fri, Jan 5, 2018 at 6:28 AM, Robert Haas wrote:
> On Tue, Jan 2, 2018 at 5:23 PM, Andres Freund wrote:
>> 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 sock
On Tue, Jan 2, 2018 at 5:23 PM, Andres Freund wrote:
> 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)
>
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,
