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 368A1C4CECE for ; Fri, 13 Mar 2020 07:21:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D6E52206EB for ; Fri, 13 Mar 2020 07:21:31 +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="drIFz0tb" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D6E52206EB 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 AB2906B0005; Fri, 13 Mar 2020 03:21:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A63C76B0006; Fri, 13 Mar 2020 03:21:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 978D76B0007; Fri, 13 Mar 2020 03:21:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0226.hostedemail.com [216.40.44.226]) by kanga.kvack.org (Postfix) with ESMTP id 7EB476B0005 for ; Fri, 13 Mar 2020 03:21:29 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 3557A824556B for ; Fri, 13 Mar 2020 07:21:29 +0000 (UTC) X-FDA: 76589493498.30.goose21_cecc9ea0ad34 X-HE-Tag: goose21_cecc9ea0ad34 X-Filterd-Recvd-Size: 4674 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf15.hostedemail.com (Postfix) with ESMTP for ; Fri, 13 Mar 2020 07:21:28 +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 D9921206EB; Fri, 13 Mar 2020 07:21:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1584084087; bh=q0cIe6MTJK09dh8sMu1JtSynCN5FdarBVPOa9V6hUXw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=drIFz0tb/SZIMzAcm+iDRPxG/eOY4Vjkn03uAhYebZe1FIXXiweBhWrqEpiqs4iLv qDhpIpCEyLBLFS5yeM/GXXVfPomQ8qWJQpYFXVyaIhMmFY90EHvEMIEc7eVX4r8y9P DRRU+G/IRgIddCjGBcG2l+F+GM+qnPiyVpm3s6pc= Date: Fri, 13 Mar 2020 09:21:22 +0200 From: Leon Romanovsky To: Jaewon Kim 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 Subject: Re: [RFC PATCH 0/3] meminfo: introduce extra meminfo Message-ID: <20200313072122.GD31504@unreal> References: <20200311034441.23243-1-jaewon31.kim@samsung.com> <20200311072509.GH4215@unreal> <5E6B0E72.7010305@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5E6B0E72.7010305@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 Fri, Mar 13, 2020 at 01:39:14PM +0900, Jaewon Kim wrote: > > > On 2020=EB=85=84 03=EC=9B=94 11=EC=9D=BC 16:25, Leon Romanovsky wrote: > > On Wed, Mar 11, 2020 at 12:44:38PM +0900, Jaewon Kim wrote: > >> /proc/meminfo or show_free_areas does not show full system wide memo= ry > >> 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 p= ages > >> , ion system heap memory, graphics memory, and memory for DRAM based > >> compressed swap storage. They may be shown in other node but it seem= s to > >> useful if /proc/meminfo shows all those extra memory information. An= d > >> 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 91537fee0= 013 > >> ("mm: add NR_ZSMALLOC to vmstat") but not on /proc/meminfo. > >> > >> Memory usage of specific driver can be various so that showing the u= sage > >> through upstream meminfo.c is not easy. To print the extra memory us= age > >> 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 GraphicDriv= er::13091kB > >> <6>[ 420.856450] active_anon:957205 inactive_anon:159383 isolated_= anon:0 > > The idea is nice and helpful, but I'm sure that the interface will be= abused > > almost immediately. I expect that every driver will register to such = API. > > > > First it will be done by "large" drivers and after that everyone will= copy/paste. > I thought using it is up to driver developers. > If it is abused, /proc/meminfo will show too much info. for that device= . > What about a new node, /proc/meminfo_extra, to gather those info. and n= ot > corrupting original /proc/meminfo. I don't know if it is applicable for all users, but for the drivers such info is better to be placed in /sys/ as separate file (for example /sys/class/net/wlp3s0/*) and driver/core will be responsible to register/unregister. It will ensure that all drivers get this info without need to register and make /proc/meminfo and /proc/meminfo_extra too large. Thanks > > Thank you > > Thanks > > > > >