Hi, On 2019-05-15 12:52:47 +1200, Thomas Munro wrote: > On Wed, May 15, 2019 at 10:31 AM Andres Freund <and...@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
