On 6/29/23 01:34, Andres Freund wrote: > Hi, > > On 2023-06-28 23:26:00 +0200, Tomas Vondra wrote: >> Yeah. FWIW I was interested what the patch does in practice, so I >> checked what pahole says about impact on struct sizes: >> >> AllocSetContext 224B -> 208B (4 cachelines) >> GenerationContext 152B -> 136B (3 cachelines) >> SlabContext 200B -> 200B (no change, adds 4B hole) >> >> Nothing else changes, AFAICS. I find it hard to believe this could have >> any sort of positive benefit - I doubt we ever have enough contexts for >> this to matter. > > I don't think it's that hard to believe. We create a lot of memory contexts > that we never or just barely use. Just reducing the number of cachelines > touched for that can't hurt. This does't quite get us to reducing the size to > a lower number of cachelines, but it's a good step. > > There are a few other fields that we can get rid of. > > - Afaics AllocSet->keeper is unnecessary these days, as it is always allocated > together with the context itself. Saves 8 bytes. > > - The set of memory context types isn't runtime extensible. We could replace > MemoryContextData->methods with a small integer index into mcxt_methods. I > think that might actually end up being as-cheap or even cheaper than the > current approach. Saves 8 bytes. > > Tthat's sufficient for going to 3 cachelines. > > > - We could store the power of 2 for initBlockSize, nextBlockSize, > maxBlockSize, instead of the "raw" value. That'd make them one byte > each. Which also would get rid of the concerns around needing a > "mini_size_t" type. > > - freeListIndex could be a single byte as well (saving 7 bytes, as right now > we loose 4 trailing bytes due to padding). > > That would save another 12 bytes, if I calculate correctly. 25% shrinkage > together ain't bad. >
I don't oppose these changes, but I still don't quite believe it'll make a measurable difference (even if we manage to save a cacheline or two). I'd definitely like to see some measurements demonstrating it's worth the extra complexity. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
