On 8/1/21 11:07 PM, Andres Freund wrote:
Hi,
On 2021-08-01 19:59:18 +0200, Tomas Vondra wrote:
In the attached .ods file with results, the "comparison" sheets are the
interesting ones - the last couple columns compare the main metrics for the
two patches (labeled patch-1 and patch-2) to master.
I assume with patch-1/2 you mean the ones after the benchmark patch
itself?
Yes, those are the two WIP patches you shared on 19/7.
Overall, the results look quite good - patch-1 is mostly on par with master,
with maybe 5% variability in both directions. That's expected, considering
the patch does not aim to improve performance.
Not for slab anyway...
Maybe the hot/cold separation could have some effect, but probably not
for the workloads I've tested.
The second patch brings some nice improvements - 30%-50% in most cases (for
both allocation and free) seems pretty nice. But for the "increase" FIFO
pattern (incrementally allocating/freeing more memory) there's a significant
regression - particularly for the allocation time. In some cases (larger
chunks, block size does not matter too much) it jumps from 25ms to almost
200ms.
I'm not surprised to see some memory usage increase some, but that
degree of time overhead does surprise me. ISTM there's something wrong.
Yeah, the higher amount of allocated memory is due to the couple fields
added to the SlabBlock struct, but even that only affects a single case
with 480B chunks and 1kB blocks. Seems fine to me, especially if we end
up growing the slab blocks.
Not sure about the allocation time, though.
It'd probably worth benchmarking the different improvements inside the
WIP: slab performance. patch. There's some that I'd expect to be all
around improvements, whereas others likely aren't quite that clear
cut. I assume you'd prefer that I split the patch up?
Yeah, if you split that patch into sensible parts, I'll benchmark those.
Also, we can add more interesting workloads if you have some ideas.
This seems unfortunate - the allocation pattern (FIFO, allocating more
memory over time) seems pretty common, and the slowdown is significant.
Did you analyze what causes the regressions?
No, not yet. I'll run the same set of benchmarks for the Generation,
discussed in the other thread, and then I'll investigate this. But if
you split the patch, that'd probably help.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
