Re: slab allocator performance issues
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: John Naylor <john.naylor@enterprisedb.com>
Cc: Tomas Vondra <tomas.vondra@enterprisedb.com>,
Andres Freund <andres@anarazel.de>, pgsql-hackers@postgresql.org, Tomas Vondra <tv@fuzzy.cz>
Date: 2022-12-20T08:51:37Z
Lists: pgsql-hackers
On Tue, 20 Dec 2022 at 21:19, John Naylor <john.naylor@enterprisedb.com> wrote: > > > On Tue, Dec 20, 2022 at 10:36 AM David Rowley <dgrowleyml@gmail.com> wrote: > > > > I'm planning on pushing the attached v3 patch shortly. I've spent > > several days reading over this and testing it in detail along with > > adding additional features to the SlabCheck code to find more > > inconsistencies. > > FWIW, I reran my test from last week and got similar results. Thanks a lot for testing that stuff last week. I got a bit engrossed in the perf weirdness and forgot to reply. I found they made much more sense after using palloc0 and touching the allocated memory just before freeing. I think this is a more realistic test. I've now pushed the patch after making a small adjustment to the version I sent earlier. David
Commits
-
Improve the performance of the slab memory allocator
- d21ded75fdbc 16.0 landed