From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BA390274FFD for ; Sat, 21 Feb 2026 08:29:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771662585; cv=none; b=TnJrhOeNW6Ujz03VG5BQHlj+9Qk8YYHhKeubhbfzFMc5DHnS8mzpwIqORMUv1f3bpLlHWJ8V9PzwY1dI4Lj+mhCqjcCF52kDCa02ym78/Mn4T/il11N8tkWWLVKtj3E1M9fu0lgdMOs6Vgo5P2KITVFsWpS3PgLkALJmA+S4tEk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771662585; c=relaxed/simple; bh=/KF7N9P8kwaG42Pz8uYG3PDsHTexNl7EceRjmbNSDCs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=q/4of4V6i+kmz6wad8zNGpZDGHnhjkSNdmb40sSbjB/ZMjXmmN74cVccbi5Hn2jiIPZiM6fP+U44ZqUttCsJScuhb+6qI37Zz28z3pojQJzakxTuplMS9y5ckjqaSbt4B9ECNsbMwdxeRGcVcYyzq08TaE6T/XF4lieU+vTdYNY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rLj5z5cP; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="rLj5z5cP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 58EE1C4CEF7; Sat, 21 Feb 2026 08:29:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771662585; bh=/KF7N9P8kwaG42Pz8uYG3PDsHTexNl7EceRjmbNSDCs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=rLj5z5cPPxcGa2FkpzYEDztmPckQy/FikbVToMmEYiwy8ViOVnQFMadQj7EmUZ0Kx N2ry1dyjJbCcBR9eWQH1hoQ7VJPItPSrO4rXASmFcV6A81JRN4MgEFHlKF93tt4ZgZ /zAv+FIXCh3yg+eDGmCykFiNskLmbQLkccoRUHDTb5PWFrF73C/LHH1XyD0AUzrHPA wOjgkApFBm5XAS6lAv5vFZ/Y1YToGBox3IF69VbIe/Ztm9rtz/dGnBRZvJ+eGL76n0 aBJOizlaJQ4WN4Ee8xpHIfcSIgBGOgVXsw1gRA7Df8r8ltMVu+/clmMhPLsC2+i+yc i+4bLZx7hA0OQ== Date: Sat, 21 Feb 2026 10:29:39 +0200 From: Mike Rapoport To: "Guilherme G. Piccoli" Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-dev@igalia.com, kernel@gpiccoli.net, Andrew Morton , Steven Rostedt Subject: Re: [PATCH 0/2] Some small improvements to reserve_mem Message-ID: References: <20260217195816.861684-1-gpiccoli@igalia.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260217195816.861684-1-gpiccoli@igalia.com> Hi Guilherme, On Tue, Feb 17, 2026 at 04:45:05PM -0300, Guilherme G. Piccoli wrote: > Currently the "reserve_mem" parsing is lacking information both > if it works or not. It can fail in many ways, so I'm adding some > messages to help users determine failure. Yep, these are useful. > At the same time, if it succeeds, the only place I can "see" it > is in the accounting of reserved memory, as the following kernel message: > > [0.086881] Memory: 3958852K/4189472K available (19671K kernel code, 2893K rwdata, 9724K rodata, 4340K init, 5040K bss, 220244K reserved, 0K cma-reserved) > > Since "crashkernel=" reservations are shown in both kernel log and /proc/iomem > and other unused memory buffers appear in /proc/iomem as "RAM buffer" entries, > I've added hereby a debugfs entry for "reserve_mem". Though I didn't love the > implementation, I think it's not so hideous so decided to send, please lemme > know what you think and if we should improve code or even discard the idea heheh crashkernel reservations are part of the ABI and kexec tools parse them in userspace, so they should be exposed. reserve_mem consumers are in the kernel, so if the reservation succeeds there's no real need for userspace to see where are the reserve_mem regions. I don't generally object showing them in debugfs, but the changelog for debugfs addition should give more details why they would be useful rather than just say that unlike crashkernel they don't show up anywhere. > Notice that, with this change, the memblock debugfs folder ends-up showing > always, no matter if we have ARCH_KEEP_MEMBLOCK set or if reserve_mem is set. > Thanks in advance for reviews/comments! > > > Guilherme G. Piccoli (2): > mm/memblock: Print out errors on reserve_mem parser > mm/memblock: Add reserve_mem debugfs info > > mm/memblock.c | 65 ++++++++++++++++++++++++++++++++++++++++++--------- > 1 file changed, 54 insertions(+), 11 deletions(-) > > -- > 2.50.1 > > -- Sincerely yours, Mike.