Re: v13: Performance regression related to FORTIFY_SOURCE

From: Andres Freund <andres(at)anarazel(dot)de>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Peter Geoghegan <pg(at)bowt(dot)ie>
Subject: Re: v13: Performance regression related to FORTIFY_SOURCE
Date: 2020-06-05 21:49:17
Message-ID: 20200605214917.hsz4q5z25mgph5zb@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2020-04-19 15:07:22 -0700, Jeff Davis wrote:
> I brought up an issue where GCC in combination with FORTIFY_SOURCE[2]
> causes a perf regression for logical tapes after introducing
> LogicalTapeSetExtend()[3]. Unfortunately, FORTIFY_SOURCE is used by
> default on ubuntu. I have not observed the problem with clang.
>
> There is no reason why the change should trigger the regression, but it
> does. The slowdown is due to GCC switching to an inlined version of
> memcpy() for LogicalTapeWrite() at logtape.c:768. The change[3] seems
> to have little if anything to do with that.

FWIW, with gcc 10 and glibc 2.30 I don't see such a switch. Taking a
profile shows me:

│ nthistime = TapeBlockPayloadSize - lt->pos;
│ if (nthistime > size)
3.01 │1 b0: cmp %rdx,%r12
1.09 │ cmovbe %r12,%rdx
│ memcpy():

│ __fortify_function void *
│ __NTH (memcpy (void *__restrict __dest, const void *__restrict __src,
│ size_t __len))
│ {
│ return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
2.44 │ mov %r13,%rsi
│ LogicalTapeWrite():
│ nthistime = size;
│ Assert(nthistime > 0);

│ memcpy(lt->buffer + lt->pos, ptr, nthistime);
2.49 │ add 0x28(%rbx),%rdi
0.28 │ mov %rdx,%r15
│ memcpy():
4.65 │ → callq memcpy(at)plt
│ LogicalTapeWrite():

I.e. normal memcpy is getting called.

That's with -D_FORTIFY_SOURCE=2

With which compiler / libc versions did you encounter this?

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2020-06-05 22:20:57 Re: Trouble with hashagg spill I/O pattern and costing
Previous Message Alvaro Herrera 2020-06-05 21:19:43 Re: Trouble with hashagg spill I/O pattern and costing