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 9E84BC25B74 for ; Mon, 27 May 2024 16:24:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CF7D46B008C; Mon, 27 May 2024 12:24:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CA74D6B0092; Mon, 27 May 2024 12:24:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B6E686B0093; Mon, 27 May 2024 12:24:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 999936B008C for ; Mon, 27 May 2024 12:24:27 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 14C9A141053 for ; Mon, 27 May 2024 16:24:27 +0000 (UTC) X-FDA: 82164698574.30.8AFE5A5 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf16.hostedemail.com (Postfix) with ESMTP id 521BD18001C for ; Mon, 27 May 2024 16:24:25 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=bKnIPKTO; spf=pass (imf16.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1716827065; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=amGuLXQcI4+L97SjfTtpQOTld2CNdiwD5oYEWy2a0LY=; b=eUWrG28xmc/SFcNjES1cNtbWgvk8Wl+WQ7gSp1VP26q5ZDnUmB1mxY7nPICZv+5Hga35tF A5lijdbn8rTw54cRW+dclyPNYxsGKdsvAqNEes8qim4N//LQbNM/MJ/a5FblxBpvP7625g qbVT/QvXeBZ8zlvTa75Do1q4oDSTe/I= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1716827065; a=rsa-sha256; cv=none; b=VCuO8VngAd1rpXf4pcvmZstod5V6HmalKolYI8sexLvpKwy0cnxk1LKeDMqiUCBJQ1EG49 AbELYXUyGBYaqKZUFs5BKOfPmD6B1NlPsS/daey+kHGE1PjU4ezp2CqzeDDaTtdTYsVeWf 5VTnstViSmng3ldIZtmL96lC0eEeuRw= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=bKnIPKTO; spf=pass (imf16.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 3F3666196F; Mon, 27 May 2024 16:24:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AF4EAC32789; Mon, 27 May 2024 16:24:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1716827063; bh=PgMG8Nl4HW/frSEexzbSY5VEC+HJRgX+juJE9zXQsSo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=bKnIPKTOd1Ifou5xt4csJYw733fCEaV6tSXDjNtxd1rExGVMOebjmIefiycpEkpyr M4b5JV2jfbN/KY9dMchyigO5c9ks+h/oC34GnHTDrdNyd8cKRigRr5IJzaa/CBhSsx krHZXoYvMB8kxz9UVkpvQIrvxe/+AX8feryEOPl5VcPyNyXuIVGHpHdiQ6msNtYk7L vKm4WpPXJbWgwc1AigzcUzNFE7/AtJ0nU3WPGsLOvx8kjsd+g1tJw3YrBlDsieL65f FZoTkNR6tozVwFk+9jWPBA7guzEtM5Xpdi4xiBpgViAyQnoxn42bRIjU3f5UMFcGM8 65r2KD1aRtb1g== Date: Mon, 27 May 2024 19:22:36 +0300 From: Mike Rapoport To: Jaewon Kim Cc: "vbabka@suse.cz" , "akpm@linux-foundation.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "jaewon31.kim@gmail.com" , "tkjos@google.com" , Wei Yang , Pintu Agarwal Subject: Re: (2) [RESEND PATCH 00/10] memblock: introduce memsize showing reserved memory Message-ID: References: <20240521023957.2587005-1-jaewon31.kim@samsung.com> <20240521025329epcms1p6ce11064c0f0608a0156d82fda7ef285c@epcms1p6> <20240521101753epcms1p50443f6b88adea211dd9bbb417dd57cb1@epcms1p5> <20240524090715epcms1p274939a1d5954be3423f6ce14a3df6f92@epcms1p2> <20240527013504epcms1p22bec7b83f2a42e76877b97ed0d769009@epcms1p2> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240527013504epcms1p22bec7b83f2a42e76877b97ed0d769009@epcms1p2> X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 521BD18001C X-Rspam-User: X-Stat-Signature: ic55xm7bn9pkg86wmtnirmcibkoeiknq X-HE-Tag: 1716827065-663481 X-HE-Meta: U2FsdGVkX18gvzTIyiyIIOY06yRHIzcjbAG0cRuea2BrFkm4lMXWjDzduQhj6i7rlIP5U3RaHx5bsHz60h8+0wwoWdYIfON2CUODx5lBsVy050BYPLDNN7XLKtIKg79GfGv0DSk1fHzgXt95liW7pxxPWYvrKbMyPTsZH/87nVSyZrrF7hHsPPe5VIy9x1z0Cos+kyzbEMZtWAZtLh/TscxcG+5oQcOpOXNBp1Qst2/YWDxdeyWVxADbpTKOTUX3vSaM0xqe819IiEYHJbs/nGHzbUEfXNHhC1pRtwyFP6BtpiZ2Ss5rSzPAPG7K+C1ktTG2ap1/IiAicgzgNnZcWF2f86oA5vQ5Gl51doVOX3LqZ/UafbOmoCXzFwbqLGf3kQQpekvYXdDJt6expl9FPhuemK5E9jBk+BXioPlCA8egZ7EDCrIUQSnWERzJlo6KCib8Q/6yP0flLRSzk0SkbOyhgo7gc9We0V6KBUl+7tvug2uIeLoB6W1CXiowyqG7vf9ztPmlubcZIJViKzjIMCYe9JC2hY946t7x94ZrybcKNJm7bGmTfgC88K+E8Zk3jJCg9X6ka5vd12K2SVtQjXYhUzHDfHCpeEmPHhnHUGcTG7qsGW9EVv0YW3jPiJUSkaXOcbWG6hUxQKNvPDHHvsIdW/lQAGQwE59Q9MMswkI3JEIeMclACuPdG3kiInEif1YK0tHt1x8y5XYiwYGfOEX3UoJuDdaNF8ErqOsSATINgtxfJlnwzH3lcMtWYYvjOOOOdbBsFYVkxEyJ2bKVUTx1wz/nC8UUGybp69Potm0zwoqjpeaOKfrjYcPGWCxtgK+vfPxuA3CeybZeEztoQDAQg6LmRTgabQj9zcluKtgGj/atpVyigKdxFLj9STV/CO8VkHHAff+sX5p6rpnPmlud1IImSMGCcwHTxjsPeozRQexlzOmdIVb8sGyp2IvLlDuldDTEtMhYs88HB3p Ov7NyWh6 l79zLYuiSxfdHZtBuaSUZZG5fowQhDdkrqOgtG0tZJcTmyGaA+fq2OyYPIJh50sw/kdeSjt1i46WnI5QQspbns9GqJPIhppk+5IkbM86j60Bt0Vv2vrNKJZobFVK0ef38+K/NrdLe3fWUYdpnS1TORdeq3g06h82TjAgZXjYw/WZdkLMt66OQoCviRKOMoA5afg/VURc5MPE27Uzxg/ueZxwfQVVnWUFcP5/NuT2hrnqgwnxpg3+VbWKMoihTBap2Km58+sWsPrMVameRPipYERDG6sIyGA7GM4SwrpY/vhiYbt3+KCUs8W+7B9c10cb3hVPJYj62q92BR0DKcWmeDQreXgLiabt5ymilovlUlxuZkSw= 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: List-Subscribe: List-Unsubscribe: On Mon, May 27, 2024 at 10:35:04AM +0900, Jaewon Kim wrote: > >On Fri, May 24, 2024 at 06:07:15PM +0900, Jaewon Kim wrote: > >> >On Tue, May 21, 2024 at 07:17:53PM +0900, Jaewon Kim wrote: > >> >> >On Tue, May 21, 2024 at 11:53:29AM +0900, Jaewon Kim wrote: > >> >> >> > >> >> >> This is actually RESEND as it was introduced 2 years ago. > >> >> >> Please refer to https://lore.kernel.org/linux-mm/YkQB6Ah603yPR3qf@kernel.org/#t > >> >> >> > >> >> >> > But you never provided details about *why* you want this information exposed. > >> >> >> > >> >> >> For your question, I'd like to say ; > >> >> >> We can see the same format and exact information between different version of kernel status. > >> >> >> > >> >> >> 1) Internally we can check if the reserved memory changes. > >> >> >> 2) Externally we can communicate between chipset vendors and OEM, with a same format. > >> >> > > >> >> >Why the existing debugfs interface is not sufficient? > >> >> > >> >> debugfs/memblock/memory & debugfs/memblock/reserved have changed its > >> >> format but still does not show name, reusable, kernel size. If memory is > >> >> reserved from memblock, and did not freed back to memblock. Memblock does > >> >> not know even after the memory is freed to system. I think a simple > >> >> debug interface is needed to easily communicate with others or compare > >> >> different SW releases. > >> > > >> >I still don't understand what problem are you trying to solve with these > >> >patches. > >> > >> I think we need a common API to easily see the reserved memory status. > >> Through MemTotal on /proc/meminfo, we can only see only the total size > >> of reserved memory. We don't how big kernel init size within the the > >> total size. I think this really helps to compare different kernel and > >> communicate with others. > > > > As was already mentioned on this thread, something like > > > > $ dmesg | grep Memory: > > [ 0.000000] Memory: 8058204K/8388608K available (35392K kernel code, 8706K rwdata, 23320K rodata, 16832K init, 848K bss, 297636K reserved, 32768K cma-reserved) > > > > already shows init, rodata and bss sizes. > > > > And size -A vmlinux provides detailed breakdown of the kernel image into > > sections. > > > >> I think the debugfs API or early boot log shows quite much information > >> for the reserved memory information defined in device tree. But it is > >> difficult to see after boot, as the boot log already was removed ouf of > >> the kernel log buffer. > > > > Kernel log is persisted, isn't it? > > Early kernel log is removed after other log is written to the log buffer. I may > not be able to get it, after waiting for the target device is ready to be > connected from host PC. I wanted to keep that information. > > Actually the commit aeb9267eb6b1 ("of: reserved-mem: print out reserved-mem > details during boot") seems to show most of information if I can get the early > boot log. Unless the kernel log is stored on the target you need to redirect target's console to a file on the host, then all of the boot log will be accessible on the host. Then with memblock=debug kernel parameter you'll be able to get much more information about memblock reservations. > If you don't mind, let me ask one question. How can we easily find the undefined > DRAM memory regions in kernel persective. Do we have to look into the debugfs > memblock/memory and combine the information with the kernel log information? > > case1) Actual DRAM is mapped as two regions like, > 2GB @ 0x00000000_80000000 and 6GB @ 0x00000008_80000000, > how can we find the hole, 0x00000000_80000000--0x00000008_7FFFFFFF ? The actual memory banks reported to Linux are shown at debugfs/memblock/memory > case2) If some region is already carved out at bootloader stage like. > 0x00000000_81200000-0x00000000_812FFFFF was not initinally on memblock. > 0x00000000_80000000-0x00000000_81200000 was removed as no-map through device tree. > how can we find the hole, 0x00000000_81200000-0x00000000_812FFFFF ? nomap regions are shown in debugfs/memblock/memory as NOMAP. -- Sincerely yours, Mike.