Received-SPF: pass (google.com: domain of linux-kernel+bounces-119604-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Date: Tue, 26 Mar 2024 17:33:12 +0000
From: Catalin Marinas <catalin.marinas@arm.com>
To: Waiman Long <longman@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] mm/kmemleak: Compact kmemleak_object further
Message-ID: <ZgMG2DOyL6qwfBfr@arm.com>
References: <20240307190548.963626-1-longman@redhat.com>
 <20240307190548.963626-2-longman@redhat.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240307190548.963626-2-longman@redhat.com>

On Thu, Mar 07, 2024 at 02:05:47PM -0500, Waiman Long wrote:
> With commit 56a61617dd22 ("mm: use stack_depot for recording kmemleak's
> backtrace"), the size of kmemleak_object has been reduced by 128 bytes
> for 64-bit arches. The replacement "depot_stack_handle_t trace_handle"
> is actually just 4 bytes long leaving a hole of 4 bytes. By moving up
> trace_handle to another existing 4-byte hold, we can save 8 more bytes
> from kmemleak_object reducing its overall size from 248 to 240 bytes.
> 
> Signed-off-by: Waiman Long <longman@redhat.com>

Acked-by: Catalin Marinas <catalin.marinas@arm.com>