Hi,
On 2019-05-15 12:52:47 +1200, Thomas Munro wrote:
> On Wed, May 15, 2019 at 10:31 AM Andres Freund <andres@anarazel.de> wrote:
> > *Without* disabling SMT, for readonly pgbench, I'm seeing regressions
> > between 7-11%, depending on the size of shared_buffers (and some runtime
> > variations). That's just on my laptop, with an i7-6820HQ / Haswell CPU.
> > I'd be surprised if there weren't adversarial loads with bigger
> > slowdowns - what gets more expensive with the mitigations is syscalls.
>
> Yikes. This all in warm shared buffers, right?
Not initially, but it ought to warm up quite quickly. I ran something
boiling down to pgbench -q -i -s 200; psql -c 'vacuum (freeze, analyze,
verbose)'; pgbench -n -S -c 32 -j 32 -S -M prepared -T 100 -P1. As both
pgbench -i's COPY and VACUUM use ringbuffers, initially s_b will
effectively be empty.
> So effectively this is the cost of recvfrom() and sendto() going up?
Plus epoll_wait(). And read(), for the cases where s_b was smaller than
the data.
> Did you use -M prepared?
Yes.
> If not, there would also be a couple of lseek(SEEK_END) calls in
> between for planning... I wonder how many more syscall-taxing
> mitigations we need before relation size caching pays off.
Yea, I suspect we're going to have to go there soon for a number of
reasons.
- Andres