Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp4860721pxb; Mon, 28 Mar 2022 04:44:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxEWsn6kqDL/P4Qk4waZWcMvHbXukt/8moi7bb+twlZB8ZnefHTgYvY+7fxN35rdSUYH/is X-Received: by 2002:a17:907:7f93:b0:6db:7634:f214 with SMTP id qk19-20020a1709077f9300b006db7634f214mr27338414ejc.3.1648467875661; Mon, 28 Mar 2022 04:44:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1648467875; cv=none; d=google.com; s=arc-20160816; b=QF7EoeEJgWW8BBo4772e96SSDROzVE7V3wUa1rfuKPYlLYpwgXKnHeKhFNWZMT6xW8 5r9Tv2hcSR+NWGACslnhFc5gbkXiy+5nsir6+5C7e5D9WzH2PvifkPIdfvHABuuyUp+h C3UgWz69xvrAm0gh1ingD0YkGaJIFk1rhZ+2wlbmwoIOtYNVzcz2tGj2a3gcoh6T+plu wlyDr6eE1SI2GnCqRbsxxVOqgjj2Ti0Zkclqdfw6m9dGA5h55LvQG1M2pzHv7jr+HWd2 icHSZ68/LrmP0gfCSfoEcOsvE7718qd3neBBOx4XGBFTkZpao6YTqlVSY+8DV07+SUpx Obbg== 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=SjKYmZUD+jJXCKFmtTnngS12gN/uMyQl6WEDUh+50ks=; b=tKas5CJKTTLbQJBHy2GsPBaqC+53HorGmyS5CdE5Q3UyE9OyYP3X1oDchzH/CT98q6 y62nrFO+khT76UUaCP6Cdr2KSy8yw6yeK/EmCzGB8W6Sxm7salcdv45OvywNef19CBi1 Vla8R42hCqKjaMmMApUBWXb2O6ZH8FZEqM8LZNLCe/wRi0tuGz/apBWf1jEs42b6sUkB C3gGDqzQVU51XIGWRLvkxRpYZeiCvzt1JHl6ePzpQ6gVW0qdeO2TnFJzh/mIxCXJcGqi WwKgAN/JHB3wBsks2pyjKmMvkAJa4PX2xlKKmMrs9llRutp5+gFfs3YVDq/DxhpgJwau di2g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=u16gBWss; 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 oz16-20020a170906cd1000b006df76385c62si13054285ejb.258.2022.03.28.04.44.07; Mon, 28 Mar 2022 04:44:35 -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=u16gBWss; 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 S235824AbiC0PRE (ORCPT + 99 others); Sun, 27 Mar 2022 11:17:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39592 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235584AbiC0PRC (ORCPT ); Sun, 27 Mar 2022 11:17:02 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 653C150B1E for ; Sun, 27 Mar 2022 08:15:24 -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 dfw.source.kernel.org (Postfix) with ESMTPS id 0220561036 for ; Sun, 27 Mar 2022 15:15:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 05176C340EC; Sun, 27 Mar 2022 15:15:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1648394123; bh=Hl0LXWoiLzrKX6l1Eq/43l5hDVxWTAXk31ja3k+z+ZY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=u16gBWssceWp1pZoEzsr2VAt8LlB6WKPEzcsCxfqNMA22jp4UYuDOwdmE4lDRwI3J YkJX5q5CorWKR0QBLmdvSlc9Tnb1sVFHYc/RaOIDabn+kYr2H4dRxy15iJhjjwPY1+ 9tg4b/Q8/rcnTAI6aV52vWernTiarCalzcdsKWbRDC6xf0Pfxcwu65Jn0/tjZvVJTU /L2I5StgosR+jakn9tbHYgHdj6AQB/kDNYbE/tYiACoFj/6jbmoYJvCA1k379+m1NN Jo4jVyBoOhwrYJFczNtZlB0d19NPVci5h7I1ep2BDh5X658N7ZT9kYLaAwEcENBNc+ EA8e2MNk4c9kw== Date: Sun, 27 Mar 2022 18:15:15 +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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220327135347epcms1p13faf0f2b7d98d3b59b25e903678d9c48@epcms1p1> 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 On Sun, Mar 27, 2022 at 10:53:47PM +0900, Jaewon Kim wrote: > > > >--------- Original Message --------- > >Sender : Mike Rapoport > >Date : 2022-03-27 16:40 (GMT+9) > >Title : Re: [PATCH 0/8] memblock: introduce memsize showing reserved memory > > > > > >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. > Thank you > Jaewon Kim -- Sincerely yours, Mike.