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 9E6A0C25B76 for ; Mon, 3 Jun 2024 09:33:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 24B616B00A3; Mon, 3 Jun 2024 05:33:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 222836B00A5; Mon, 3 Jun 2024 05:33:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 09D176B00A6; Mon, 3 Jun 2024 05:33:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id E0C986B00A3 for ; Mon, 3 Jun 2024 05:33:20 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 993F91C1CED for ; Mon, 3 Jun 2024 09:33:20 +0000 (UTC) X-FDA: 82189064160.19.4739389 Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by imf10.hostedemail.com (Postfix) with ESMTP id 29ABAC0015 for ; Mon, 3 Jun 2024 09:33:14 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=samsung.com header.s=mail20170921 header.b=GJXHNQFy; spf=pass (imf10.hostedemail.com: domain of jaewon31.kim@samsung.com designates 203.254.224.24 as permitted sender) smtp.mailfrom=jaewon31.kim@samsung.com; dmarc=pass (policy=none) header.from=samsung.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717407196; a=rsa-sha256; cv=none; b=exBUNjICYkuvFsNKyII+u2E2PfydyPTy/yDzE9MLkdFjDQTkP2RvhzTZeivp3CF4lNkH4x oca4HkgHnK2ZPlTXUVn6nCk9VExqbMbt3gz3Ceh7fsj8gS2RJk6p61eN2/aNpBDMqGvPn+ L5LjrqMQNi3Nn4UT4pXrqrBOFzID014= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=samsung.com header.s=mail20170921 header.b=GJXHNQFy; spf=pass (imf10.hostedemail.com: domain of jaewon31.kim@samsung.com designates 203.254.224.24 as permitted sender) smtp.mailfrom=jaewon31.kim@samsung.com; dmarc=pass (policy=none) header.from=samsung.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717407196; h=from:from:sender:sender:reply-to: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=nP+t4EIY6o5//ZwZPwCa4ZNSh3wzvVaaEWbfgsBy5qA=; b=O8x2DCVYc64tpO8EyvnNkqw6gjR34kowBtxge1PR+GNx9zS8nkN+keKnCDTJg96Df3Iy+5 /HVtkh8Rao5kskpWjrLyu9pU8Hr8Lz6wx+J7fgRkyKQhS5r9xSjCv7zO9U5rcylPx3JgKB nagjtKKHeJOt4Kw1k9Rmd61pI77sXsM= Received: from epcas1p4.samsung.com (unknown [182.195.41.48]) by mailout1.samsung.com (KnoxPortal) with ESMTP id 20240603093311epoutp01fadb0b8cc2e6df968e901b92dc005311~VdL3joOqB0576505765epoutp01e for ; Mon, 3 Jun 2024 09:33:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.samsung.com 20240603093311epoutp01fadb0b8cc2e6df968e901b92dc005311~VdL3joOqB0576505765epoutp01e DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1717407191; bh=nP+t4EIY6o5//ZwZPwCa4ZNSh3wzvVaaEWbfgsBy5qA=; h=Subject:Reply-To:From:To:CC:In-Reply-To:Date:References:From; b=GJXHNQFyCHlZB5yy8LvE/wK2CJ53chHydlv4w+JEKuBkTURdcLbfWKWHMeGTvSBhq ZujeHbVsr3zDmuXdeYjFFPcbdpCKdBrxXF+7StXJz4t/OfTqPrl1c/NGZLISAExrEh wXSlIx4Ux9i89BJGqXQZH5F0TUt0YShPBJucHU+o= Received: from epsnrtp2.localdomain (unknown [182.195.42.163]) by epcas1p1.samsung.com (KnoxPortal) with ESMTP id 20240603093311epcas1p1ac2d110fc8c801da19a85f31110fe080~VdL2zJhwM3008530085epcas1p1I; Mon, 3 Jun 2024 09:33:11 +0000 (GMT) Received: from epsmges1p4.samsung.com (unknown [182.195.38.241]) by epsnrtp2.localdomain (Postfix) with ESMTP id 4Vt7nL48lSz4x9Q9; Mon, 3 Jun 2024 09:33:10 +0000 (GMT) X-AuditID: b6c32a38-ff1fa7000000287a-31-665d8dd6929a Received: from epcas1p2.samsung.com ( [182.195.41.46]) by epsmges1p4.samsung.com (Symantec Messaging Gateway) with SMTP id 76.2C.10362.6DD8D566; Mon, 3 Jun 2024 18:33:10 +0900 (KST) Mime-Version: 1.0 Subject: RE: (2) (2) [RESEND PATCH 00/10] memblock: introduce memsize showing reserved memory Reply-To: jaewon31.kim@samsung.com From: Jaewon Kim To: "richard.weiyang@gmail.com" , Jaewon Kim CC: Jaewon Kim , Mike Rapoport , "vbabka@suse.cz" , "akpm@linux-foundation.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "tkjos@google.com" , Pintu Agarwal X-Priority: 3 X-Content-Kind-Code: NORMAL In-Reply-To: <20240601014045.jkk3ydsu4zns2bfc@master> X-Drm-Type: N,general X-Msg-Generator: Mail X-Msg-Type: PERSONAL X-Reply-Demand: N Message-ID: <20240603093310epcms1p893f1ed36c0531917b69eb77e3ddfd794@epcms1p8> Date: Mon, 03 Jun 2024 18:33:10 +0900 X-CMS-MailID: 20240603093310epcms1p893f1ed36c0531917b69eb77e3ddfd794 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" CMS-TYPE: 101P X-CPGSPASS: Y X-CPGSPASS: Y X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKJsWRmVeSWpSXmKPExsWy7bCmnu613tg0g7+75C3mrF/DZvHykKZF 9+aZjBa9718xWVzeNYfN4t6a/6wW119OY7G40/eKxeLI+u1MFu8nF1vMbuxjdOD22DnrLrvH gk2lHptWdbJ5bPo0id3jxIzfLB59W1YxepxZcITd4/MmuQCOqGybjNTElNQihdS85PyUzLx0 WyXv4HjneFMzA0NdQ0sLcyWFvMTcVFslF58AXbfMHKAzlRTKEnNKgUIBicXFSvp2NkX5pSWp Chn5xSW2SqkFKTkFZgV6xYm5xaV56Xp5qSVWhgYGRqZAhQnZGW/33WAteK9QcWq5cQPjX6ku Rk4OCQETiS0vJjJ1MXJxCAnsYJSYunoBkMPBwSsgKPF3hzBIjbBAvETf3FZGEFtIQEni7I8r 7BBxXYmm7tUsIDabgLbE+wWTWEFsEYEUidZFh9lBZjILPGaSWLZ+LTPEMl6JGe1PWSBsaYnt y7eCDeUUMJWYMfcxE0RcVOLm6rfsMPb7Y/MZIWwRidZ7Z6HmCEo8+LkbKi4lsezrXKj6Yoll nQ+g5tRIrDi3ig3CNpdoeLsSzOYV8JWY92U6I8iPLAKqEj/mCEKUuEjcWPga7DRmAXmJ7W/n MIOUMAtoSqzfpQ8R5pN497WHFeaTho2/2bGxd8x7AnWBmkTLs69Q9TISf/89g7I9JO5e280y gVFxFiKgZyFZPAth8QJG5lWMYqkFxbnpqcWGBSbwqE3Oz93ECE6vWhY7GOe+/aB3iJGJg/EQ owQHs5IIb19ddJoQb0piZVVqUX58UWlOavEhRlOgjycyS4km5wMTfF5JvKGJpYGJmZGJhbGl sZmSOO+ZK2WpQgLpiSWp2ampBalFMH1MHJxSDUzMou1HNZ5H8Bv7Ll+WHcKkvlLx4HMlv3zm 2RnP6u6f4pv4gP1kgA2L1bzdu8ON3RJi6g2WP+1oKmnJm/jgnt61u57Mtw+9UVQSCb96/P9t AWth/b6wzOOS9z/sYXEIdOpxFhC8NOnn3iVX50ysnKTzUPuhn/vmfU+r605K/dl3cNb65pOC T+P3pLG6sO0O5b69JjJOP7svbdKJ/lWSHw4sv2Zg8/R/xnRnzS/ajHoq55szZ62cf73x+skn ea03bv+VCzxzcFra/cvzT+Xd8In5qBqTWJ/ZwXW7+dvD21NmhOjOYG69PnHLm1XLz25lL2UI /ftX8IDos6U/Jt5jqTE8a/Tc2OHgicQfDz7d3Pk9S4mlOCPRUIu5qDgRAPgVaVE4BAAA DLP-Filter: Pass X-CFilter-Loop: Reflected X-CMS-RootMailID: 20240521024009epcas1p10ed9f9b929203183a29f79508e79bb76 References: <20240601014045.jkk3ydsu4zns2bfc@master> <20240521025329epcms1p6ce11064c0f0608a0156d82fda7ef285c@epcms1p6> <20240521101753epcms1p50443f6b88adea211dd9bbb417dd57cb1@epcms1p5> <20240524090715epcms1p274939a1d5954be3423f6ce14a3df6f92@epcms1p2> <20240527013504epcms1p22bec7b83f2a42e76877b97ed0d769009@epcms1p2> <20240529095119epcms1p73f0e9ff756bcb2ee6a14db459128a644@epcms1p7> <20240529113519.jupuazcf754zjxzy@master> <20240530104928epcms1p8108ece61c39c6e3d0361d445c15352d1@epcms1p8> <20240531082141epcms1p49d8d2048e04e90eca45644723614faa8@epcms1p4> X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 29ABAC0015 X-Stat-Signature: hj1cb8go78x3sijzyhqtbjb9yj5dtynk X-HE-Tag: 1717407194-862046 X-HE-Meta: U2FsdGVkX18yuj8MnViLGfvfaR8JzvDkigoWbAKaQlgQ1h1EgEm3elBeBklycdCzWRdMt2jeiJBkNTUbvVr4URbHMgwYLMqmNacPvLQcCA5g9tJFzoBW6ZoKv/caA+Nx/rDImmIf8/IjV6my4Yxwf4bnIQ783BfEEkwx/6rtiykbLPU0rXc28FQRWBtg+jVnJVv1hPgHEHRQe1Pz74AX7Bmf+hch1ZDH3E2of2Lhf3CWexyttfxFeoifXdStIuXFRuWDeRuiygFTWL7TzFCWFeCKyRQpkt/iApOfKAObbB3YxRYwSh7wAi+QYRvR6hY+TZW1G4ZFR0eN3dDkAdUjgpk6IWeZ1e9siLoKIzV6lgsB/1Zotn+cVN2BFtURNXvvL1NiPCuvPrbZsOPqogNXeQjC/xPj69PqVspjcHVqWlhqR/TabqoHVdO3VTuvQ2O+MgoIDvc23rbBiLriaVz1CuAwWo9mOYWuissyDwOt/GA4z2rSKvU/IQ6PJEPhiTkzbDfnvDPeyaaDd0mBTtdSHPQNmFVbCxr4gxZda4fiJQ39otICHd4T6+5w3E/TpJM8ZfmXFZx31y9EbnRm8tojncLiaenHwiWEy6togmBwTQpsCWKTxBCrdU9B71i88bQq3YtvIsXKpehSdnGcAuAG7/VY7sxEd9GcY8z8XsCZ9ax95jppD6gDh0MLA6jZu51nDENYDD8S5Klj6CMfHgIGcRhBaZlA5LT5/rGL7TOuSV56ALDviTJizRqfuqPsFO7IKQeB9GMIx4bfOnfTktmZHZHsXHdJt14QfPgJ3TSAUx2zL5YJ5N6yrOsQ92uqV+wF9RTXsJX5oIX0w/LikyEpVqf5eIsyMgVCC0ZwxLeh+g4arMoDMHop3BH940kpuklDpWUdlkjjcSq0JNzzj1otGgUjOmBor0SBz8LyqgJYXa0ecme4id5LXFiznTg5sP7YOgFsw2oaG9iGgqH/nss ykDjZn09 zEWLvKsxdeeZzFiyvVUoqxolI2NwcSw7SXwQpTn3qPua50PXwndW8R5oA4DWAKMYB2BkRdzuCliXddoiuBScOFDNkmRDpsRzUIrWhCyLqdYnhJ6zTEkMT7NpVYwvjBSF1MxzPLFGrbVzN4ARny7IU5QyLLpzYxFWFe1hR/iWwbC50aIycfxxXjEpZXIfwaTnC/vZ4mhoDDSDD4c/eHGhOSikPX3zkvJNCZMYrbFBCXyiHGu6FscsHX8CvxUITivs0XiZJNN4+LBLGD6p3W2HVbuXX024wuK0vDJZl9L37JpCq9IDiq2Y/CG+nHjlRG+D/L4lbovyMbs38iRg= 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 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 >