Received-SPF: pass (google.com: domain of linux-kernel+bounces-35385-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Tue, 23 Jan 2024 13:26:23 +0000
From: Matthew Wilcox <willy@infradead.org>
To: Charan Teja Kalla <quic_charante@quicinc.com>
Cc: Liam.Howlett@oracle.com, "linux-mm@kvack.org" <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: Purpose of maple_node objects to be its size aligned
Message-ID: <Za--f_sJ8cbgqn80@casper.infradead.org>
References: <56154bf4-c1e2-16d5-c6e2-c2dee42d3377@quicinc.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <56154bf4-c1e2-16d5-c6e2-c2dee42d3377@quicinc.com>

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.