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 0811EC433EF for ; Wed, 30 Mar 2022 07:08:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 60B7A8D0002; Wed, 30 Mar 2022 03:08:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5BC7A8D0001; Wed, 30 Mar 2022 03:08:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 482798D0002; Wed, 30 Mar 2022 03:08:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 36B978D0001 for ; Wed, 30 Mar 2022 03:08:35 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id D427F8248D52 for ; Wed, 30 Mar 2022 07:08:34 +0000 (UTC) X-FDA: 79300174548.18.0073E26 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf03.hostedemail.com (Postfix) with ESMTP id 4E60720004 for ; Wed, 30 Mar 2022 07:08:34 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 5EB27B81AD7; Wed, 30 Mar 2022 07:08:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D3E8AC340EC; Wed, 30 Mar 2022 07:08:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1648624111; bh=DKoq9YvSczGdQCdMOF+NabMNKq/zWi6ZojZmF4Zj6bs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Vw7ByWb4Xkwu28+hAngRXO/bi3ONlQPQQSQuEAAKhnzXh8yqY4cjj71nGa1yMpBPi XwSwIEUfQWCnD3+xERtK8mKgw59ZSaD4cBV4i39F/aFKx9TFDp0xSXPTcviilSwUmx 3Xa8Wv/GhTUgvTx7PtQBsmwavkqa4onOYQ5ynKrt9Guq1TF7lPZ7nG/pyPpVPfSpoB yXax5RUPkQOVN+0QfbyJFjRwCOE0u7nTRBxdmFj6Lo3z5yHoeisnZph4nL3CNvKhsw Mexhqqt37niEoHaqeA+vuLOrK3oA/bPeqPPpDrgEvy2AbH9TQaiKJ/pXmDN2jilQeo zvJOaUE6E8IVw== Date: Wed, 30 Mar 2022 10:08:24 +0300 From: Mike Rapoport To: Jaewon Kim Cc: "vbabka@suse.cz" , "akpm@linux-foundation.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , YongTaek Lee , "jaewon31.kim@gmail.com" Subject: Re: [PATCH 0/8] memblock: introduce memsize showing reserved memory Message-ID: References: <20220324070158.22969-1-jaewon31.kim@samsung.com> <20220325083846epcms1p372559472ceb511cc45d39c110563063a@epcms1p3> <20220327135347epcms1p13faf0f2b7d98d3b59b25e903678d9c48@epcms1p1> <20220329024620epcms1p7633018e83f54e532761008a60da5254f@epcms1p7> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220329024620epcms1p7633018e83f54e532761008a60da5254f@epcms1p7> Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Vw7ByWb4; spf=pass (imf03.hostedemail.com: domain of rppt@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 4E60720004 X-Stat-Signature: tqbnwaqymenya71k9raixmw1fzujm1gs X-HE-Tag: 1648624114-365557 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi, On Tue, Mar 29, 2022 at 11:46:20AM +0900, Jaewon Kim wrote: > >> > > >> >I'm still not following. The reserved region sizes are available in the > >> >existing memblock debugfs. > >> >Why the names are important? What is the value of having names for *some* > >> >of the reserved regions? > >> > >> Hi > >> > >> There are many memory regions in memblock debugfs memory/reserved, and some might > >> be splited or merged with other region. Among regions in debugfs, we can't find > >> the one we defined in device tree. Especially it is difficult to find the region we > >> described size only without start address. > >> > >> On mobile environment, memory is used by not only CPU but also GPU, Camera, Secure > >> world, Audio, ETC. To support them, there are many reserved regions described in > >> device tree. So the name is quite important to recognize a region. And with thename > >> we can compare reserved memory map with other map. > > > >You still didn't describe your use case. What is the problem your patches > >are trying to solve? Why is it important to know what is the use of particular > >reserved region? > > > >You propose complex mechanism that seems to fit very particular scenario > >and sprinkle some calls to this mechanism at random places because you need > >to "compare reserved memory map with other map". > > > >Does not sound convincing to me, sorry. > > As I said serveral times, I want a simple knob showing all reserved > memory status. The current debugfs, device tree do not show all those > information I want. I think you also know that. i.e. late freed pages, > splited or merged memblock, address defined at boot time, kernel size, > ETC. I know that there is not much information about reserved memory exposed and I understand *what* are you trying to achieve. But you never provided details about *why* you want this information exposed. I don't mind providing more visibility into reserved memory attributes in general, but I'd like to see something way more simple and localized. -- Sincerely yours, Mike.