Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp2114021pxb; Wed, 30 Mar 2022 16:59:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxYka/gHHec/zOe2QYuS27Fxss03FLLPhDr7CdvDrSFt9O5yrUAFfZQ82UV0HOklbc9Zl+Q X-Received: by 2002:a05:6a00:cd2:b0:4fa:abfe:e0eb with SMTP id b18-20020a056a000cd200b004faabfee0ebmr2273899pfv.66.1648684788822; Wed, 30 Mar 2022 16:59:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1648684788; cv=none; d=google.com; s=arc-20160816; b=CMbvqxs4sdQOZkdt5JOJwCV6O3A5uuXyXNcLC33bDxYqEQfB3Ua+y4JHhzN3v0jEpx /6jeyQmvufDNqJTMbKdVQwnx5u3tcF3sybFyOXMWUMhmIIjAQw9I4RUuARfve7mz3cnc kIS+nsYoIV3RRK2HkdNUAxRmZ6BVj1A+yXIQlA2I8UHqKmVpbrZT3W99SxgoO2dcH5fA 93hCgq8rOL2nlCCDkkFU5xPWmgdSIuk9jQ5wQvBr82ARfNeUnkBBkA+llFXrtrYVP1jQ rOc0faWB0NrQaO0Ffp3lMYu6Rmf6mj5bwzE8kzlq/yG3VDQoC0qlMtcW87rr+UNFdkOS +FhQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=aVYi89852JuV7k2B+R+WqBZOf7rIM9HyO1Po2r3TFFw=; b=mSX7uhWfDmnKUW3b12Pu2mtTqm28aggvddoSuhnvPYm9glUCbOa5Ii7t2x39mUhaw7 9hVN6Y5K8fOCsJPV2K+3IBQiWZHvDkjUvWGcQWtX+UKqtZwNexv1Afq2WT2q5LqA64/T etH1CcJo0oNZHcIQWfIsgUr6tAS6EbYqeY6NkLr5EENHlRPGYFiLLqjZG1NM4XxJNsaR 8D2kTQuD5ckgbpRj9VSGHKIB8fdHfnVGYMi4EI1NwjLHNsWL2CP40YZ8rEEqeKKjc9hM FQd77TxlHU2SevfaMfCmD1XKIGxaZpAPGC+yl/EN9b+33zyxgD9MPboGoVwaHgkZl62V 5bEQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Vw7ByWb4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id k17-20020a63d851000000b0038253c42afesi22777514pgj.104.2022.03.30.16.59.35; Wed, 30 Mar 2022 16:59:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Vw7ByWb4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243639AbiC3HKX (ORCPT + 99 others); Wed, 30 Mar 2022 03:10:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55116 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242546AbiC3HKS (ORCPT ); Wed, 30 Mar 2022 03:10:18 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AFC7014925D for ; Wed, 30 Mar 2022 00:08:33 -0700 (PDT) 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 627AEB81B7B for ; 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> X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.