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. Greetings, Andres Freund
