[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240523092317epcms1p220c5ebd665d2c7b6a8a43e884926573b@epcms1p2>
Date: Thu, 23 May 2024 18:23:17 +0900
From: 김재원 <jaewon31.kim@...sung.com>
To: "richard.weiyang@...il.com" <richard.weiyang@...il.com>,
김재원 <jaewon31.kim@...sung.com>
CC: Mike Rapoport <rppt@...nel.org>, "vbabka@...e.cz" <vbabka@...e.cz>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "jaewon31.kim@...il.com"
<jaewon31.kim@...il.com>, "tkjos@...gle.com" <tkjos@...gle.com>
Subject: RE: [RESEND PATCH 00/10] memblock: introduce memsize showing
reserved memory
>[...]
>>
>>Hi
>>
>>> Maybe you can show the log difference, so that we can see how it helps you.
>>
>>For your new email, could you elaborate the difference you meant?
>>Do you mean difference between existing debugfs membock interfaces and the one I introdued here?
>>
>
>You mentioned the difference between kernel version helps you locate the
>problem. That is the difference of your new debugfs.
Correct. Actually we get many SW release from chipset vendors. Even though
their kernel version is same, the reserved memory status varies. So we can
easily compare them.
BR
>
>
>--
>Wei Yang
>Help you, Help me
Powered by blists - more mailing lists