Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp4122492pxb; Sun, 27 Mar 2022 12:31:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwmURUYVMlZsybV7/Y37BLsVKkyMwnFIBETHVqnoQIKj0/77XJKWl+/1+cOEUZt19SzHrB+ X-Received: by 2002:a50:fb05:0:b0:419:2600:e439 with SMTP id d5-20020a50fb05000000b004192600e439mr11885089edq.71.1648409484122; Sun, 27 Mar 2022 12:31:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1648409484; cv=none; d=google.com; s=arc-20160816; b=Xx8qkde21T+xRBJBFoiSG09x09FxX2tEo0ot7DQA7c6GatSr/gPCFafUZLDCP+r6l4 +cVKhxgsHobsGd/bLomtSSNOxa1KLVCuSukymaovVkAA2pQcfROTNkJRJimQKDpXHd4n Ek/3g6EbjyW5Z37ZGJE+gTXff6P4zcw1kJMtd+21qi1YiZlvuXPlwPP87tR9vWsyAO49 05sfiEoEmlOUu+A2Bl8nRaEwX256K/Ev0Wf8jfbXX/x9JWsQA6xJk/h11g9VZngsbYof zcgoYR7/aq4pE5woXxBdAPxYp6+4slY7weFm4s9v6cgDs3gMoWhXEEkIiRZP5rV+POhj j89A== 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=3miv/MNrtuAZcV9quhkiP17FvWefdI5x5nXyyk66H7o=; b=ijjMGhqXQYbJfBgmeSaBtJndNM7rO+OlWI/joRA//ErdbOFVKJBEUqhCTv+2GNMJQH /mprgiqFT9IwDoULh/Az0ZulFleyG0ezF5JCOw/GkxVev0+LHq3ghDC5BjbWYCuIBvnD f5hbbwhiV8IKH+SaUaFtZpI9BuHXbAf4QI1wLR8dXDjder9mw78xDn3ETxwlzMuRuXsL 2PanF04ZrMuh2hdr8hxTpHf1WXs/XH/BuPoXaJXtLGouV6QKQOhwObSWYxb8VjjBVxZo NEW0uFfJ/IHZ0SK1WhMaa3cZfT4cpLO8c10vEKPdt/07+hEfCZDB5/Lpzx3Vt/kvhyvs JeFA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=DlvBMXDB; 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 u21-20020a170906409500b006df76385b8esi10657792ejj.46.2022.03.27.12.30.55; Sun, 27 Mar 2022 12:31:24 -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=DlvBMXDB; 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 S235616AbiC0HmB (ORCPT + 99 others); Sun, 27 Mar 2022 03:42:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51706 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232063AbiC0Hl4 (ORCPT ); Sun, 27 Mar 2022 03:41:56 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 79870389D for ; Sun, 27 Mar 2022 00:40:18 -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 1450360F71 for ; Sun, 27 Mar 2022 07:40:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A652EC340EC; Sun, 27 Mar 2022 07:40:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1648366817; bh=uvNqC6FYSmHZzEP2jIiGJCsBXoTHRrNBW+V3s9qnniM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=DlvBMXDB8Txvep4tW3NHi+uthhwM605Q46pX0y/tWlFiwMZf+hqLkwxGndrdq+bac eeyDuIuTxU5LE5/ZSq0IQ15gNRONBiazD1kSNT6V/XZ+JEZvI1Kpz/4TNu1pgtZ2Tn IbiaxTEj+Q1CQPdclkCvoedwiEN9YoT6e6dJbW7RG1P8FpSAiFa4nlHVWm+mabMvoq HEhdnzUEI3cHVBK3M0YoxojABGep9rWKcTLybJyx9l6RbK1ps5MPgozk5sN3qFB2CJ ie3i7QoDafP2Fn3+dlAV/wgff6WvvIEoQnAHQ63QhI229KfDV8k98na5kKl8rU3Hr2 yY0s8UhkhQGgw== Date: Sun, 27 Mar 2022 10:40:08 +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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220325083846epcms1p372559472ceb511cc45d39c110563063a@epcms1p3> X-Spam-Status: No, score=-7.9 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 Fri, Mar 25, 2022 at 05:38:46PM +0900, Jaewon Kim wrote: > >--------- Original Message --------- > >Sender : Mike Rapoport > >Date : 2022-03-25 16:46 (GMT+9) > >Title : Re: [PATCH 0/8] memblock: introduce memsize showing reserved memory > > > >Hi, > > > >On Thu, Mar 24, 2022 at 04:01:50PM +0900, Jaewon Kim wrote: > >> Some of memory regions can be reserved for a specific purpose. They are > >> usually defined through reserved-memory in device tree. If only size > >> without address is specified in device tree, the address of the region > >> will be determined at boot time. > >> > >> We may find the address of the memory regions through booting log, but > >> it does not show all. And it could be hard to catch the very beginning > >> log. The memblock_dump_all shows all memblock status but it does not > >> show region name and its information is difficult to summarize. > >> > >> This patch introduce a debugfs node, memblock/memsize, to see reserved > >> memory easily. > >> > >> Here's an example > >> > >> $ cat debugfs/memblock/memsize > >> 0x0f9000000-0x0fb000000 0x02000000 ( 32768 KB ) map reusable linux,cma > >> 0x0b1900000-0x0b1b00000 0x00200000 ( 2048 KB ) nomap unusable test1 > >> 0x0b0200000-0x0b0400000 0x00200000 ( 2048 KB ) map unusable test2 > >> (snipped) > >> > >> Reserved : 746924 KB > >> .kernel : 137027 KB > >> .text : 28158 KB > >> .rwdata : 3238 KB > >> .rodata : 13468 KB > >> .bss : 12570 KB > >> .etc : 79593 KB > >> .unusable : 609897 KB > >> System : 3447380 KB > >> .common : 3152468 KB > >> .reusable : 294912 KB > >> Total : 4194304 KB ( 4096.00 MB ) > > > >Most of this information information is already available at various > >places, like the existing memblock debugfs, /proc/iomem and DT sysfs. > > > >I don't see why we need yet another debugfs file to expose it. > > Hi. > Thank you for your reply. > > Especially I'd like to create a node showing all reserved memory status, their > total size is same as the physical memory size. This was very useful when I > compare reserved memory and kernel init time memory between different chipsets, > or between different sw release versions. 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? > Thank you > Jaewon Kim -- Sincerely yours, Mike.