| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: PSA: New intel MDS vulnerability mitigations cause measurable slowdown |
| Date: | 2019-05-15 00:52:47 |
| Message-ID: | CA+hUKGJCorbJpiwzf=JfbYJx_Ov=h9yW1SJ9UtaemuJTJYF7zA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, May 15, 2019 at 10:31 AM Andres Freund <andres(at)anarazel(dot)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? So effectively this
is the cost of recvfrom() and sendto() going up? Did you use -M
prepared? 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.
--
Thomas Munro
https://enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2019-05-15 01:06:46 | Re: PSA: New intel MDS vulnerability mitigations cause measurable slowdown |
| Previous Message | Amit Langote | 2019-05-15 00:34:10 | Re: PostgreSQL 12: Feature Highlights |