On Tue, Jan 23, 2024 at 04:33:51PM +0530, Charan Teja Kalla wrote: > I am just curious about the purpose of maple node slab objects to be its > size aligned, but I can understand why they need to be cache aligned. Because we encode various information in the bottom few bits of the maple node pointer. /* * The Maple Tree squeezes various bits in at various points which aren't * necessarily obvious. Usually, this is done by observing that pointers are * N-byte aligned and thus the bottom log_2(N) bits are available for use. We * don't use the high bits of pointers to store additional information because * we don't know what bits are unused on any given architecture. * * Nodes are 256 bytes in size and are also aligned to 256 bytes, giving us 8 * low bits for our own purposes. Nodes are currently of 4 types: * 1. Single pointer (Range is 0-0) * 2. Non-leaf Allocation Range nodes * 3. Non-leaf Range nodes * 4. Leaf Range nodes All nodes consist of a number of node slots, * pivots, and a parent pointer. */ > Reason for the ask is, when slub debug enabled with option Z, the change > [1] makes the total object to be 256 * 3 (=768)bytes. This turns out to > be a problem in debug builds where the unreclaimable slab consumption > itself is very high thus exerting the memory pressure on the system. That seems like a very badly implemented patch. Rather than make all objects left & right redzone, we should simply insert a redzone at the beginning of the slab. ie 0 redzone 256 node 512 redzone 768 node 1024 redzone 1280 node [...] 3072 redzone 3382 node 3584 redzone 3840 wasted space Instead of getting only five nodes per 4kB page, we'd get seven; about a 30% reduction in memory usage. Slab redzoning is not a feature people turn on often, so I'm not surprised nobody's noticed before now.
