From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 75115C47258 for ; Tue, 23 Jan 2024 13:26:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CB1796B0071; Tue, 23 Jan 2024 08:26:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C614C6B0078; Tue, 23 Jan 2024 08:26:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B297F6B007B; Tue, 23 Jan 2024 08:26:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id A2DC86B0071 for ; Tue, 23 Jan 2024 08:26:30 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 4DAEE120A51 for ; Tue, 23 Jan 2024 13:26:30 +0000 (UTC) X-FDA: 81710650140.30.37C7EC5 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf04.hostedemail.com (Postfix) with ESMTP id 7FF0B40015 for ; Tue, 23 Jan 2024 13:26:26 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=irijOS1Q; dmarc=none; spf=none (imf04.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706016387; a=rsa-sha256; cv=none; b=G1L3tOIguu0L98YyoK8B7BKae6oiLuO1Lp138hoq0rMyKegbxvoFjEZ2virMHdYU4BHBHF sCSZ8erBdEV5DeCs5KQNEZ7VsmiWv1dCpx7AEBl8Va+bBmTQ+4JyGXpIHrUNB3SiRXNUGG FwPvQsbz3+NJd/9o6S0hzHinhmqIfkE= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=irijOS1Q; dmarc=none; spf=none (imf04.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706016387; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=/ZCMocwMPamrl65ph5MZuGdO38zWJwVsJZU5ToyF4Tk=; b=mqkdXLUUuEJWXEl9xIlJJt5zvUvu2+WdND1Kgl+g+oX0yadhS9Z75LwiLQ9FQQ6aDipYw1 VpU6eRFDYDelil0E8rwcC1BAo5rOi/Gda4UvREwGEwP5em4qvjZ9EseE6mTPajJeJ7LCuf u5wrjZr3/GWm8WXT2/0rLe327uFTzk4= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=/ZCMocwMPamrl65ph5MZuGdO38zWJwVsJZU5ToyF4Tk=; b=irijOS1QnyXiGeqKvQYbe5ci7z gsNEQzafeZo/J2zav79FBsPs7Mjgc/MiHL8vblhCRLhSXWgYYL6Hlwhs/d7avUgLZatmUXufm0rrD Y6D9H8C6JJ0rGVFirMQtNbrooET5zfK2FDJzoZwRBMxCcoqSYRrB0b+wKpqyIX0PsjqIVX4k/sL8e wDr2CmRiIyoIfYsw2WKPqT0tOBhsJdxIl11zi02rW3tHLH3qa1EPWaF57dCL+R5I24XrnCuM2r4u3 UCgbwNVLR3oaIxqcZJyQ7a89PdAZQQoNmOqILsAx2qqxkX6QG7qhDoTPgpsxaIp9CfHS6FBvP/wgm N1bYTJtQ==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rSGnH-00000003HYT-1hlQ; Tue, 23 Jan 2024 13:26:23 +0000 Date: Tue, 23 Jan 2024 13:26:23 +0000 From: Matthew Wilcox To: Charan Teja Kalla Cc: Liam.Howlett@oracle.com, "linux-mm@kvack.org" , LKML Subject: Re: Purpose of maple_node objects to be its size aligned Message-ID: References: <56154bf4-c1e2-16d5-c6e2-c2dee42d3377@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56154bf4-c1e2-16d5-c6e2-c2dee42d3377@quicinc.com> X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 7FF0B40015 X-Stat-Signature: oc8zad3ntih8yjupj7hr6zoyqmoc4sum X-HE-Tag: 1706016386-60873 X-HE-Meta: U2FsdGVkX1+WYs5nqLCR1LiWFN7PxJIstiW/yK4pL3vDwL+zZPwijMnqwBabNmODO1fq/kKjK9Wo6pt6DvSNi+1Zzo5pdukyhpq6W5Yw++uEG4ne653aM9uet3sM+t3oznOl/SovyFKgVI7G9tPwNwEC3wvJUCU0NjFpCZHCyU1HEmD1JonfcgNjcSLYCkqZoFLQtfL/+wIetS37C61bMW/QZCVAIInCMwTIDMJlOSbfnGsMjG8VNuQhov4fji+R1HNxUCRIzNwdCb5pVE59Kw6S/35SrNzF7Y2vccDJ6KsqfXSkyZ70WP38/GVhCOoHypBoda15Y0If3KeKjW5GoZPnaCzwmAYFgpFRIkpJ4N86qKhBhij+fAT1hv/B1j6HiSNXBMzdRxvPUm9j1k2tGB6u23SHm1Csh2ZGDz7OAoLI0Ak8RUQTvNFKYMqS9kBV1MCzJO7BzdKwfZUzeevOHQ7FqyRvj3IvV9D/7Z7CrbjSaGJepQexvymkY+tRD8UGoDP2jP+7iUHSnP/bwjaxEpc/Omd/gtPyOk8ZSm3NSzCpTFD8Wamej30Oj0/mCPr+goToB863LjqJ+wxnwJiDMNxFo0wBml45aK2FnN0q3qD1p0Be6v7zs0G5w/NC1iXcwCS7SUXWyMDfsNpoW/KcKrQp8tAjvWsoLemBc1o043tDliTMUxfAsfvUSty2HHYa5Z4hT5w8GsxYPdVBZtY6M8mldG5t93KF+U1etK5NNxnOEfmbnPyPTzPdcGwMvqMDpauGCdvJN/vha6NYwFvJIrelcBgdjhq1cYHeBoX7QZemJN/tES+0LhGYcUZXe1rqSy7cqsPuoBlrB3uKn4RA/NGHHXzb0nIUtafnW1/7HvePrlS6OWsBMSsJk/wgFo0L+Qsl+v+Zic2ZFv4lgYGrEkDWlMOSRrjU0rwlMFywwYftBMD5fZWaEEc3zUJKpw6MJn/tw/T1Fccs7Q94kj2 9/Q5WdgK WTo8csdDlNNryE+/cRmD3PULtZOBF/hyQnucCz/tnUVWRtIe04mOHbxEzmExkGPVObgaWyD5iwq3k3XuIiEV82wcvYyi4tEX2+t1qKRTfTGEIdr7Yq0dy5xM2wmZ7znBISx+u4GsyEy9PcRzwyeEVYGqxtUPpfvAHQrheOWXNlVTKwf1Sf80j6vXxtFBxjDZLauKzclVrSaN53FMxbC/hOuQysJ/yh94v0Sv4 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000004, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 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.