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=-0.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 20E03C1975A for ; Mon, 16 Mar 2020 08:32:01 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CA34F20679 for ; Mon, 16 Mar 2020 08:32:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="IfbKFO8O" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CA34F20679 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5EAB66B0003; Mon, 16 Mar 2020 04:32:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 59CB46B0005; Mon, 16 Mar 2020 04:32:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4B1BB6B0007; Mon, 16 Mar 2020 04:32:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0167.hostedemail.com [216.40.44.167]) by kanga.kvack.org (Postfix) with ESMTP id 344A96B0003 for ; Mon, 16 Mar 2020 04:32:00 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 145C4181AEF2A for ; Mon, 16 Mar 2020 08:32:00 +0000 (UTC) X-FDA: 76600557600.26.dolls69_4b9db2e5fa04e X-HE-Tag: dolls69_4b9db2e5fa04e X-Filterd-Recvd-Size: 5998 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf15.hostedemail.com (Postfix) with ESMTP for ; Mon, 16 Mar 2020 08:31:59 +0000 (UTC) Received: from localhost (unknown [213.57.247.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id B8DDC20658; Mon, 16 Mar 2020 08:31:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1584347518; bh=G/JbKz/TJsKUzqrpwMaev68yogcQGTS/UnZoH2XPFgg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=IfbKFO8Olx7qaBdiqWuMLp8xz8Zy2G0XfEcnRj/20uRxt6mP1nmMvB3VMrQ/6a9JK QKl2lckiUNdzmL+oSMPBXcOpsQe5G+Ap88ZZHxugi3IZTn6ZYNx0FsC+y9CGEuaBs3 qJ4ckJIbWPYCIkYNW0ayNVOEoPQCBlr1kuPEIizc= Date: Mon, 16 Mar 2020 10:31:54 +0200 From: Leon Romanovsky To: Jaewon Kim Cc: Vlastimil Babka , 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 Subject: Re: [RFC PATCH 0/3] meminfo: introduce extra meminfo Message-ID: <20200316083154.GF8510@unreal> References: <20200311034441.23243-1-jaewon31.kim@samsung.com> <20200313174827.GA67638@unreal> <5E6EFB6C.7050105@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5E6EFB6C.7050105@samsung.com> 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 Mon, Mar 16, 2020 at 01:07:08PM +0900, Jaewon Kim wrote: > > > 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 mem= ory > >>> usage status. There seems to be huge hidden memory especially on > >>> embedded Android system. Because it usually have some HW IP which d= o not > >>> have internal memory and use common DRAM memory. > >>> > >>> In Android system, most of those hidden memory seems to be vmalloc = pages > >>> , ion system heap memory, graphics memory, and memory for DRAM base= d > >>> compressed swap storage. They may be shown in other node but it see= ms to > >>> useful if /proc/meminfo shows all those extra memory information. A= nd > >>> 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"). Swa= p > >>> memory using zsmalloc can be seen through vmstat by commit 91537fee= 0013 > >>> ("mm: add NR_ZSMALLOC to vmstat") but not on /proc/meminfo. > >>> > >>> Memory usage of specific driver can be various so that showing the = usage > >>> through upstream meminfo.c is not easy. To print the extra memory u= sage > >>> of a driver, introduce following APIs. Each driver needs to count a= s > >>> 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 GraphicDri= ver::13091kB > >>> <6>[ 420.856450] active_anon:957205 inactive_anon:159383 isolated= _anon:0 > >> I like the idea and the dynamic nature of this, so that drivers not = present > >> wouldn't add lots of useless zeroes to the output. > >> It also makes simpler the decisions of "what is important enough to = need its own > >> meminfo entry". > >> > >> The suggestion for hunting per-driver /sys files would only work if = there 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, t= his > > is why driver/core should be responsible for that and not drivers aut= hors. > > > > The use case which I had in mind slightly different than to look afte= r 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 separ= ate > > copies of itself. Those copies easily can take gigabytes of RAM due t= o > > 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 thei= r memory usage. > But I'd like to see overall memory usage through the one node. It is more than enough :). > > Let me know if you have more comment. > I am planning to move my logic to be shown on a new node, /proc/meminfo= _extra at v2. Can you please help me to understand how that file will look like once many drivers will start to use this interface? Will I see multiple lines? Something like: driver1 .... driver2 .... driver3 .... ... driver1000 .... How can we extend it to support subsystems core code? Thanks > > Thank you > Jaewon Kim