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 X-Spam-Level: X-Spam-Status: No, score=-2.1 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 98078C0044D for ; Mon, 16 Mar 2020 04:07:24 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 32BA420578 for ; Mon, 16 Mar 2020 04:07:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=samsung.com header.i=@samsung.com header.b="avmg36es" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 32BA420578 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=samsung.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 837E46B0003; Mon, 16 Mar 2020 00:07:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7E8DC6B0005; Mon, 16 Mar 2020 00:07:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6D6D16B0007; Mon, 16 Mar 2020 00:07:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0107.hostedemail.com [216.40.44.107]) by kanga.kvack.org (Postfix) with ESMTP id 534CE6B0003 for ; Mon, 16 Mar 2020 00:07:23 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 1D61F180AD806 for ; Mon, 16 Mar 2020 04:07:23 +0000 (UTC) X-FDA: 76599890766.11.floor71_5d60fa6341810 X-HE-Tag: floor71_5d60fa6341810 X-Filterd-Recvd-Size: 9668 Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by imf18.hostedemail.com (Postfix) with ESMTP for ; Mon, 16 Mar 2020 04:07:21 +0000 (UTC) Received: from epcas1p3.samsung.com (unknown [182.195.41.47]) by mailout1.samsung.com (KnoxPortal) with ESMTP id 20200316040718epoutp01f6b93dd1727495590c40d375e0a92053~8rTsY9e2F1536615366epoutp01d for ; Mon, 16 Mar 2020 04:07:18 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.samsung.com 20200316040718epoutp01f6b93dd1727495590c40d375e0a92053~8rTsY9e2F1536615366epoutp01d DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1584331638; bh=d/RUH2DnI9bnLtOMlJoIQfdWKOD4LySjodtnFlva8jQ=; h=Subject:To:Cc:From:Date:In-Reply-To:References:From; b=avmg36esx9qcAnqupfRIid4DfMK5c++LCpOxslb0Mbc6UxsPeTGuJkP6fi7lcIGmr Jtze8pM26j62WMJCqr6WxMZV62fj19xlL7K7WesG8YtQNRmMzjGidxaWyrtMpaw07i OBiQ+04ewYhaJIWSCE0wUAR3QrkJh8hSfCX4jnlo= Received: from epsnrtp1.localdomain (unknown [182.195.42.162]) by epcas1p3.samsung.com (KnoxPortal) with ESMTP id 20200316040717epcas1p37e0ea434b3d3a625758d6344cdf6262c~8rTsBP5n_2125321253epcas1p3T; Mon, 16 Mar 2020 04:07:17 +0000 (GMT) Received: from epsmges1p4.samsung.com (unknown [182.195.40.166]) by epsnrtp1.localdomain (Postfix) with ESMTP id 48gjS46QXnzMqYm3; Mon, 16 Mar 2020 04:07:16 +0000 (GMT) Received: from epcas1p2.samsung.com ( [182.195.41.46]) by epsmges1p4.samsung.com (Symantec Messaging Gateway) with SMTP id 55.E5.04160.47BFE6E5; Mon, 16 Mar 2020 13:07:16 +0900 (KST) Received: from epsmtrp1.samsung.com (unknown [182.195.40.13]) by epcas1p3.samsung.com (KnoxPortal) with ESMTPA id 20200316040716epcas1p3a16c3c333b74923a596f66fae5f28621~8rTqpmFmP2836328363epcas1p3k; Mon, 16 Mar 2020 04:07:16 +0000 (GMT) Received: from epsmgms1p2new.samsung.com (unknown [182.195.42.42]) by epsmtrp1.samsung.com (KnoxPortal) with ESMTP id 20200316040716epsmtrp1b021eecc8cca1bfb7a3507db2f928c21~8rTqm6sXH3093330933epsmtrp1d; Mon, 16 Mar 2020 04:07:16 +0000 (GMT) X-AuditID: b6c32a38-297ff70000001040-28-5e6efb74fa80 Received: from epsmtip2.samsung.com ( [182.195.34.31]) by epsmgms1p2new.samsung.com (Symantec Messaging Gateway) with SMTP id B4.A2.04158.47BFE6E5; Mon, 16 Mar 2020 13:07:16 +0900 (KST) Received: from [10.253.104.82] (unknown [10.253.104.82]) by epsmtip2.samsung.com (KnoxPortal) with ESMTPA id 20200316040714epsmtip2ed6746f17217020b1ce28bfd4334b2c2~8rTpJFgM52540325403epsmtip2o; Mon, 16 Mar 2020 04:07:14 +0000 (GMT) Subject: Re: [RFC PATCH 0/3] meminfo: introduce extra meminfo To: Leon Romanovsky , Vlastimil Babka Cc: adobriyan@gmail.com, akpm@linux-foundation.org, labbott@redhat.com, sumit.semwal@linaro.org, minchan@kernel.org, ngupta@vflare.org, sergey.senozhatsky.work@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, jaewon31.kim@gmail.com, Linux API From: Jaewon Kim Message-ID: <5E6EFB6C.7050105@samsung.com> Date: Mon, 16 Mar 2020 13:07:08 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20200313174827.GA67638@unreal> X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNJsWRmVeSWpSXmKPExsWy7bCmnm7J77w4g48njCymN3pZzFm/hs2i e/NMRouVe34wWUz5tZTZYvP3DjaLy7vmsFncW/Of1WLZ1/fsFhtaZrFbPJowicni1N3P7Baz G/sYHXg9ds66y+6xaVUnm8emT5PYPe5c28PmcWLGbxaP9/uusnmcWXCE3WPnp82sHp83yQVw RuXYZKQmpqQWKaTmJeenZOal2yp5B8c7x5uaGRjqGlpamCsp5CXmptoqufgE6Lpl5gDdraRQ lphTChQKSCwuVtK3synKLy1JVcjILy6xVUotSMkpMDQo0CtOzC0uzUvXS87PtTI0MDAyBapM yMn4v2kBS8FymYp7bV8YGxgfiXUxcnJICJhIPOw4zgRiCwnsYJQ41gUU5wKyPzFKbO39xArh fGOUOLxzHhtMx7zGiewQib2MEg+PH2eGcN4ySnxY8oAVpEpYwFbi5f8DQAkODhEBd4m1X4xA wswCi5gkWmeGg9hsAtoS7xdMAivnFdCSmPq1lQXEZhFQlfg6fxk7iC0qECGxY+5HRogaQYmT M5+wgIzkFNCRWDiTFWKkvETz1tlgJ0gILGKX6Py4lRniUBeJ1cvWQNnCEq+Ob2GHsKUkXva3 sUM0NDNKvJ25mRHCaWGUuLuplxGiyliit+cC2APMApoS63fpQ4QVJXb+nssIsZlP4t3XHlaQ EgkBXomONiGIEjWJlmdfWSFsGYm//55B2R4Suz9choboE0aJS3/PsU1gVJiF5LdZSB6ahbB5 ASPzKkax1ILi3PTUYsMCE+QY3sQITshaFjsY95zzOcQowMGoxMMrkZYXJ8SaWFZcmXuIUYKD WUmEt6MmO06INyWxsiq1KD++qDQntfgQoykwuCcyS4km5wOzRV5JvKGpkbGxsYWJmbmZqbGS OO/U6zlxQgLpiSWp2ampBalFMH1MHJxSDYzqelOKD7jMZP2ao7u9fl7G0118Mea2pj3Pv3z8 cUB+8j0Rdc0Qsfd+DYeXFUVrFjnFlnkkbeZ9ulDW8E5X3P+Lc5wk4qbn1p42rpt2cMmpAsea Y3vUv3xvtXC7/Tlp3bzDNpeMP/aH6/fOYExo1rQwfLdd2OvKovq7fL+52Mo+3l/sJVzkHKDE UpyRaKjFXFScCABb9mYV3gMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsWy7bCSvG7J77w4g7fHBSymN3pZzFm/hs2i e/NMRouVe34wWUz5tZTZYvP3DjaLy7vmsFncW/Of1WLZ1/fsFhtaZrFbPJowicni1N3P7Baz G/sYHXg9ds66y+6xaVUnm8emT5PYPe5c28PmcWLGbxaP9/uusnmcWXCE3WPnp82sHp83yQVw RnHZpKTmZJalFunbJXBl/N+0gKVguUzFvbYvjA2Mj8S6GDk5JARMJOY1TmTvYuTiEBLYzShx 9d4FRoiEjMSb809Zuhg5gGxhicOHiyFqXjNKXHk4lx2kRljAVuLl/wPMIDUiAu4Sa78YQdQ8 YZTY92ozE4jDLLCISeJm+3Q2kAY2AW2J9wsmsYLYvAJaElO/trKA2CwCqhJf5y8DGyoqECGx et01ZogaQYmTM5+AHcEpoCOxcCYriMksoC6xfp4QSAWzgLxE89bZzBMYBWchaZiFUDULSdUC RuZVjJKpBcW56bnFhgVGeanlesWJucWleel6yfm5mxjBMaaltYPxxIn4Q4wCHIxKPLwSaXlx QqyJZcWVuYcYJTiYlUR4O2qy44R4UxIrq1KL8uOLSnNSiw8xSnOwKInzyucfixQSSE8sSc1O TS1ILYLJMnFwSjUw+mdbJ5gXPz09RX3aSUXJRSr91UzztFX3Vs/b7dnpcVBljtq0H0xx5pPs Eoo448J1P04LPe8Yx7F7jaGk48+ynQsNW98GKwZ1TPTymRD0clHjlaOy91wdl2Vs55FuMNGc emfHn5W6/rsZ775vufcx9Nb7nrvHhPXePrTYeue7pJ70cZN8N5lmJZbijERDLeai4kQAteUJ XK0CAAA= X-CMS-MailID: 20200316040716epcas1p3a16c3c333b74923a596f66fae5f28621 X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-Sendblock-Type: SVC_REQ_APPROVE CMS-TYPE: 101P DLP-Filter: Pass X-CFilter-Loop: Reflected X-CMS-RootMailID: 20200311034454epcas1p2ef0c0081971dd82282583559398e58b2 References: <20200311034441.23243-1-jaewon31.kim@samsung.com> <20200313174827.GA67638@unreal> Content-Transfer-Encoding: quoted-printable 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: On 2020=EB=85=84 03=EC=9B=94 14=EC=9D=BC 02:48, Leon Romanovsky wrote: > On Fri, Mar 13, 2020 at 04:19:36PM +0100, Vlastimil Babka wrote: >> +CC linux-api, please include in future versions as well >> >> On 3/11/20 4:44 AM, Jaewon Kim wrote: >>> /proc/meminfo or show_free_areas does not show full system wide memor= y >>> usage status. There seems to be huge hidden memory especially on >>> embedded Android system. Because it usually have some HW IP which do = not >>> have internal memory and use common DRAM memory. >>> >>> In Android system, most of those hidden memory seems to be vmalloc pa= ges >>> , ion system heap memory, graphics memory, and memory for DRAM based >>> compressed swap storage. They may be shown in other node but it seems= to >>> useful if /proc/meminfo shows all those extra memory information. And >>> show_mem also need to print the info in oom situation. >>> >>> Fortunately vmalloc pages is alread shown by commit 97105f0ab7b8 >>> ("mm: vmalloc: show number of vmalloc pages in /proc/meminfo"). Swap >>> memory using zsmalloc can be seen through vmstat by commit 91537fee00= 13 >>> ("mm: add NR_ZSMALLOC to vmstat") but not on /proc/meminfo. >>> >>> Memory usage of specific driver can be various so that showing the us= age >>> through upstream meminfo.c is not easy. To print the extra memory usa= ge >>> of a driver, introduce following APIs. Each driver needs to count as >>> atomic_long_t. >>> >>> int register_extra_meminfo(atomic_long_t *val, int shift, >>> const char *name); >>> int unregister_extra_meminfo(atomic_long_t *val); >>> >>> Currently register ION system heap allocator and zsmalloc pages. >>> Additionally tested on local graphics driver. >>> >>> i.e) cat /proc/meminfo | tail -3 >>> IonSystemHeap: 242620 kB >>> ZsPages: 203860 kB >>> GraphicDriver: 196576 kB >>> >>> i.e.) show_mem on oom >>> <6>[ 420.856428] Mem-Info: >>> <6>[ 420.856433] IonSystemHeap:32813kB ZsPages:44114kB GraphicDrive= r::13091kB >>> <6>[ 420.856450] active_anon:957205 inactive_anon:159383 isolated_a= non:0 >> I like the idea and the dynamic nature of this, so that drivers not pr= esent >> wouldn't add lots of useless zeroes to the output. >> It also makes simpler the decisions of "what is important enough to ne= ed its own >> meminfo entry". >> >> The suggestion for hunting per-driver /sys files would only work if th= ere was a >> common name to such files so once can find(1) them easily. >> It also doesn't work for the oom/failed alloc warning output. > Of course there is a need to have a stable name for such an output, thi= s > is why driver/core should be responsible for that and not drivers autho= rs. > > The use case which I had in mind slightly different than to look after = OOM. > > I'm interested to optimize our drivers in their memory footprint to > allow better scale in SR-IOV mode where one device creates many separat= e > copies of itself. Those copies easily can take gigabytes of RAM due to > the need to optimize for high-performance networking. Sometimes the > amount of memory and not HW is actually limits the scale factor. > > So I would imagine this feature being used as an aid for the driver > developers and not for the runtime decisions. > > My 2-cents. > > Thanks > > Thank you for your comment. My idea, I think, may be able to help each driver developer to see their = memory usage. But I'd like to see overall memory usage through the one node. Let me know if you have more comment. I am planning to move my logic to be shown on a new node, /proc/meminfo_e= xtra at v2. Thank you Jaewon Kim