Received-SPF: pass (google.com: domain of linux-kernel+bounces-198909-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Precedence: bulk
Mime-Version: 1.0
Subject: RE: (2) (2) [RESEND PATCH 00/10] memblock: introduce memsize
 showing reserved memory
Reply-To: jaewon31.kim@samsung.com
Sender: Jaewon Kim <jaewon31.kim@samsung.com>
From: Jaewon Kim <jaewon31.kim@samsung.com>
To: "richard.weiyang@gmail.com" <richard.weiyang@gmail.com>, Jaewon Kim
	<jaewon31.kim@samsung.com>
CC: Jaewon Kim <jaewon31.kim@gmail.com>, Mike Rapoport <rppt@kernel.org>,
	"vbabka@suse.cz" <vbabka@suse.cz>, "akpm@linux-foundation.org"
	<akpm@linux-foundation.org>, "linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"tkjos@google.com" <tkjos@google.com>, Pintu Agarwal <pintu.ping@gmail.com>
In-Reply-To: <20240601014045.jkk3ydsu4zns2bfc@master>
Message-ID: <20240603093310epcms1p893f1ed36c0531917b69eb77e3ddfd794@epcms1p8>
Date: Mon, 03 Jun 2024 18:33:10 +0900
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
CMS-TYPE: 101P
DLP-Filter: Pass
References: <20240601014045.jkk3ydsu4zns2bfc@master>
	<20240521025329epcms1p6ce11064c0f0608a0156d82fda7ef285c@epcms1p6>
	<20240521101753epcms1p50443f6b88adea211dd9bbb417dd57cb1@epcms1p5>
	<20240524090715epcms1p274939a1d5954be3423f6ce14a3df6f92@epcms1p2>
	<20240527013504epcms1p22bec7b83f2a42e76877b97ed0d769009@epcms1p2>
	<20240529095119epcms1p73f0e9ff756bcb2ee6a14db459128a644@epcms1p7>
	<20240529113519.jupuazcf754zjxzy@master>
	<CAJrd-UuiDq-o=r7tK=CG6Q3yeARQBEAtaov2yqO6e6tBwJZoqQ@mail.gmail.com>
	<20240530104928epcms1p8108ece61c39c6e3d0361d445c15352d1@epcms1p8>
	<20240531082141epcms1p49d8d2048e04e90eca45644723614faa8@epcms1p4>
	<CGME20240521024009epcas1p10ed9f9b929203183a29f79508e79bb76@epcms1p8>

>On Fri, May 31, 2024 at 05:21:41PM +0900, Jaewon Kim wrote:
>>>On Thu, May 30, 2024 at 07:49:28PM +0900, Jaewon Kim wrote:
>>>>>On Wed, May 29, 2024 at 10:10:29PM +0900, Jaewon Kim wrote:
>>>>>>(Sorry I might forget to change to be plain text)
>>>>>>
>>>>>>Oh good thing, I did not know this patch. Thanks.
>>>>>>
>>>>>>By the way, I've tried to get memblock/memory and kernel log from a
>>>>>>device based on
>>>>>>v6.6.17 kernel device, to see upstream patches above.
>>>>>>memblok/memory does not show region for
>>>>>
>>>>>memblock/memory only shows ranges put in "memory".
>>>>>memblock/reserved shows ranges put in "reserved".
>>>>>
>>>>>If we just put them in "reserved", it will not displayed in "memory".
>>>>
>>>>Hi
>>>>Let me explain more.
>>>>
>>>>In this case, the intially passed memory starts from 0000000081960000 so memblock/memory shows as it is.
>>>>
>>>># xxd -g 8 /proc/device-tree/memory/reg
>>>>00000000: 0000000081960000 00000000000a0000  ................
>>>>00000010: 0000000081a40000 00000000001c0000  ................
>>>>
>>>># cat sys/kernel/debug/memblock/memory
>>>>   0: 0x0000000081960000..0x00000000819fffff    0 NONE
>>>>   1: 0x0000000081a40000..0x0000000081bfffff    0 NONE
>>>>
>>>># cat sys/kernel/debug/memblock/reserved
>>>>   0: 0x0000000082800000..0x00000000847fffff    0 NONE
>>>>
>>>>The memblock information in the kernel log may report like it allocated those memblock regions, as there was not overlapped even though it is already no-map.
>>>>
>>>>(I removed the name.)
>>>><6>[    0.000000][    T0] OF: reserved mem: 0x0000000080000000..0x0000000080dfffff (14336 KiB) nomap non-reusable AAA
>>>><6>[    0.000000][    T0] OF: reserved mem: 0x0000000080e00000..0x00000000811fffff (4096 KiB) nomap non-reusable BBB
>>>><6>[    0.000000][    T0] OF: reserved mem: 0x0000000081200000..0x00000000813fffff (2048 KiB) nomap non-reusable CCC
>>>><6>[    0.000000][    T0] OF: reserved mem: 0x0000000081a00000..0x0000000081a3ffff (256 KiB) nomap non-reusable DDD
>>>>
>>>
>>>This looks not printed by memblock_reserve(), right? It is printed by your own
>>>driver?
>>
>>AFAIK these log came from the commit below.
>>aeb9267eb6b1 of: reserved-mem: print out reserved-mem details during boot
>>
>>>
>>>>So a smart parser should combine the krenel log and the memblock/memory log.
>>>>
>>>>In my memsize feature shows it like this though.
>>>>
>>>>0x0000000081400000-0x0000000081960000 0x00560000 (    5504 KB ) nomap unusable unknown
>>>>
>>>>BR
>>>>
>>>
>>>I am sorry, I still not catch your point. Let me try to understand your message.
>>>
>>>You mentioned several regions, let me put them in order.
>>>
>>>(1)   0x0000000080000000..0x0000000080dfffff    printed by driver
>>>(2)   0x0000000080e00000..0x00000000811fffff    printed by driver
>>>(3)   0x0000000081200000..0x00000000813fffff    printed by driver
>>>(4)   0x0000000081400000..0x0000000081960000    expected to print in new debugfs
>>>(5)   0x0000000081960000..0x00000000819fffff    listed in reg/memory
>>>(6)   0x0000000081a00000..0x0000000081a3ffff    printed by driver
>>>(7)   0x0000000081a40000..0x0000000081bfffff    listed in reg/memory
>>>(8)   0x0000000082800000..0x00000000847fffff    listed in reserved
>>>
>>>If you just want information for region (4), sound we can do it in user-space?
>>>
>>>BTW, are region 1, 2, 3, 6, reserved in membock?
>>
>>Yes correct, I though (4) case could be shown to easily catch these hidden regions.
>>As I said, I think 1, 2, 3, 6 seem to be not passed to kernel, it was just tried as
>>they are defined in kernel device tree.
>>
>
>As you mentioned above, 1, 2, 3, 6, is printed by "of" driver. And those
>information is not shown in memblock/reserve.
>
>I am afraid the proper way is to let memblock know those ranges. Sounds "of"
>driver doesn't tell memblock about these.
>

Yes that is the reason why I added some code to 'of' driver, too. As I said,
if we don't change 'of' driver and memblck, we need a smart parser looking into
kernel log and memblock info, and understand these special cases.

BR

>>
>>>
>>>-- 
>>>Wei Yang
>>>Help you, Help me
>