Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp894700pxb; Thu, 28 Jan 2021 03:04:50 -0800 (PST) X-Google-Smtp-Source: ABdhPJw3c1HIiQjIPhIApRO4mfaRZhaO7O01Hplxb46VfTwJ46ZImfxlXp1pbG8BWlps6fXDCmII X-Received: by 2002:aa7:c459:: with SMTP id n25mr13035575edr.214.1611831890195; Thu, 28 Jan 2021 03:04:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611831890; cv=none; d=google.com; s=arc-20160816; b=NdxODNHZHyQopiAv+cAnSfkqx/4jce5gcurL/i7d7fReIHW32FOwlHJE0bDXg3A/0E 07WQ/w1pOsHFT0xmUfpoGniPu4kp/hWLM3u6gFQqGg/eIewVry0chR1GvsxbLyqhgM3D JWf8aUjRB9iMP+SB0eG7CAJtj/wY4Y3RfVZX380piY86DsztFHby18RoEPLyOVqSPSg9 ZPGV1wSlS7A6uAftCeR50hM5ZTXQ18PV1z++5ztlfA8UOTj7ePzrypydzOm9tnyffQ0g 17EzgR8jyvtLAE8zoir/dgeF+5n1HztGwpSgrCdRe3NgTDR4AaObbESsoyi8sYBMbUhb 97KQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=5XLGbbRInjNpFaYOyf93b/4KiboBjefE69X6aMvc2Gc=; b=gh+TfmA1Yxib8366INlnU711yMy4/Tx+mN8iMIeB7OxHbpJ72N0fwaYe3q7MoZMNaN raVH8GYGP9xICxbuqxf+pJvcQTROuym64m/2l5M6DqdfLi2DkEAW/SR6oCJu05SGYdHV aIl6NZIcUO83c1XdfaW7QfIa3So7grBSqLFa7gmR9Zz7xu1V80vDku5Yx0vNNaz6AUJb p+gDP7+J2ZcPP4DgfXRoyLn2qpcSks89JkoB5q5UBTGtcwU62xgXxGHv/MOVjL7QX1pT 9x0WPAaB7w5hCIRJvAZGI7gZgFc05vyTjE6+2jNFNE4uw9S/a7tLG5snFTM1hQ49Gnst hOxQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=xhO1ZeCH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q26si2720987edr.555.2021.01.28.03.04.25; Thu, 28 Jan 2021 03:04:50 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=xhO1ZeCH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229728AbhA1LB7 (ORCPT + 99 others); Thu, 28 Jan 2021 06:01:59 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54870 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229774AbhA1LBw (ORCPT ); Thu, 28 Jan 2021 06:01:52 -0500 Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 23F2BC061573 for ; Thu, 28 Jan 2021 03:01:12 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id s18so5780000ljg.7 for ; Thu, 28 Jan 2021 03:01:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=5XLGbbRInjNpFaYOyf93b/4KiboBjefE69X6aMvc2Gc=; b=xhO1ZeCHT+ywXd9+utDLPL/+gBf7zS1UylpMh4g+3XDLWjTElNL8s5TeqzFQcx0xDU gMRGcGNjTt1vvhtH/o2QHPF0VYMjVyxlxpSyyvPN/1ATsuMag3a/JVN90vQNwdRbpnEJ yZX+oy7yQOv0n1ElGuClZd+69kOK/YFv+I+Bq2V6Zpe0sXj8zQ2O1Sfo9qjBXWtQrmNL RGMTeOsnN7o4EgrNhpU6taDoZLM43jqDGSA6fIOInyrCbIKaNnd7LYJlTvlhvxDfP7y3 zFMbqjWzQ8mMLrdso+2X2fY4jG07lEP1Fiz97JwggzghoFlSWoUotJLaQXYybxQe7m3C Mf1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=5XLGbbRInjNpFaYOyf93b/4KiboBjefE69X6aMvc2Gc=; b=DkaoAg+rRO7kzxGJPhN88kwSST5mOr3x4rR1yKSZPIAugjagz0rrVa5eA3WjeB6c8V iHm4+jeCN44VNa80sBnfqid2GmWQ/c+IDevxfkeLkRBCXyG3BG8WpmzdKBlhisXJ+Tkc 2Y0C1CMeqI94y1T04Z+5GJlobib8dwv0+e96lDOiO2YXjc72cpon8hpDnLT66ephpOiT svMd0U3EYs/EgsjiZH0UzReax81v1wNGwUTuQh9qrdH/UZQsjsVIXPQTt3EXWSSprcON kOBTv9lNaHLwfRl+x5axXaOAICgA2UpNrkAZvy4sEw84sXZ2F18Yt8RpMkIZphtT4ADx 9mCQ== X-Gm-Message-State: AOAM532Y9y/+m20edEYbuio6dhpJwPiE6pc1xdpsNkmfwTERr9XEmXXo sqtXPhZQsmOqub/TAmTpD9+fqkQXEBIO3sMLqyR4Uw== X-Received: by 2002:a05:651c:1206:: with SMTP id i6mr6913016lja.460.1611831670558; Thu, 28 Jan 2021 03:01:10 -0800 (PST) MIME-Version: 1.0 References: <20210126204240.418297-1-hridya@google.com> In-Reply-To: From: Sumit Semwal Date: Thu, 28 Jan 2021 16:30:59 +0530 Message-ID: Subject: Re: [PATCH v3] dmabuf: Add the capability to expose DMA-BUF stats in sysfs To: =?UTF-8?Q?Christian_K=C3=B6nig?= Cc: Hridya Valsaraju , LKML , "open list:DMA BUFFER SHARING FRAMEWORK" , DRI mailing list , Linaro MM SIG , Android Kernel Team , John Stultz , Suren Baghdasaryan , hyesoo.yu@samsung.com, kernel test robot , Greg KH Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Hridya, On Wed, 27 Jan 2021 at 17:36, Greg KH wrote: > > On Tue, Jan 26, 2021 at 12:42:36PM -0800, Hridya Valsaraju wrote: > > This patch allows statistics to be enabled for each DMA-BUF in > > sysfs by enabling the config CONFIG_DMABUF_SYSFS_STATS. > > > > The following stats will be exposed by the interface: > > > > /sys/kernel/dmabuf/buffers//exporter_name > > /sys/kernel/dmabuf/buffers//size > > /sys/kernel/dmabuf/buffers//attachments//devi= ce > > /sys/kernel/dmabuf/buffers//attachments//map_= counter > > > > The inode_number is unique for each DMA-BUF and was added earlier [1] > > in order to allow userspace to track DMA-BUF usage across different > > processes. > > > > Currently, this information is exposed in > > /sys/kernel/debug/dma_buf/bufinfo. > > However, since debugfs is considered unsafe to be mounted in production= , > > it is being duplicated in sysfs. > > > > This information will be used to derive DMA-BUF > > per-exporter stats and per-device usage stats for Android Bug reports. > > The corresponding userspace changes can be found at [2]. > > Telemetry tools will also capture this information(along with other > > memory metrics) periodically as well as on important events like a > > foreground app kill (which might have been triggered by Low Memory > > Killer). It will also contribute to provide a snapshot of the system > > memory usage on other events such as OOM kills and Application Not > > Responding events. > > > > A shell script that can be run on a classic Linux environment to read > > out the DMA-BUF statistics can be found at [3](suggested by John > > Stultz). > > > > The patch contains the following improvements over the previous version= : > > 1) Each attachment is represented by its own directory to allow creatin= g > > a symlink to the importing device and to also provide room for future > > expansion. > > 2) The number of distinct mappings of each attachment is exposed in a > > separate file. > > 3) The per-buffer statistics are now in /sys/kernel/dmabuf/buffers > > inorder to make the interface expandable in future. > > > > All of the improvements above are based on suggestions/feedback from > > Daniel Vetter and Christian K=C3=B6nig. > > > > [1]: https://lore.kernel.org/patchwork/patch/1088791/ > > [2]: https://android-review.googlesource.com/q/topic:%22dmabuf-sysfs%22= +(status:open%20OR%20status:merged) > > [3]: https://android-review.googlesource.com/c/platform/system/memory/l= ibmeminfo/+/1549734 > > > > Signed-off-by: Hridya Valsaraju > > Reported-by: kernel test robot Thanks for the patch! Christian: If you're satisfied with the explanation around not directly embedding kobjects into the dma_buf and dma_buf_attachment structs, then with Greg's r-b from sysfs PoV, I think we can merge it. Please let me know if you feel otherwise! > > --- > > Changes in v3: > > Fix a warning reported by the kernel test robot. > > > > Changes in v2: > > -Move statistics to /sys/kernel/dmabuf/buffers in oder to allow additio= n > > of other DMA-BUF-related sysfs stats in future. Based on feedback from > > Daniel Vetter. > > -Each attachment has its own directory to represent attaching devices a= s > > symlinks and to introduce map_count as a separate file. Based on > > feedback from Daniel Vetter and Christian K=C3=B6nig. Thank you both! > > -Commit messages updated to point to userspace code in AOSP that will > > read the DMA-BUF sysfs stats. > > > > > > .../ABI/testing/sysfs-kernel-dmabuf-buffers | 52 ++++ > > drivers/dma-buf/Kconfig | 11 + > > drivers/dma-buf/Makefile | 1 + > > drivers/dma-buf/dma-buf-sysfs-stats.c | 285 ++++++++++++++++++ > > drivers/dma-buf/dma-buf-sysfs-stats.h | 62 ++++ > > drivers/dma-buf/dma-buf.c | 37 +++ > > include/linux/dma-buf.h | 20 ++ > > 7 files changed, 468 insertions(+) > > create mode 100644 Documentation/ABI/testing/sysfs-kernel-dmabuf-buffe= rs > > create mode 100644 drivers/dma-buf/dma-buf-sysfs-stats.c > > create mode 100644 drivers/dma-buf/dma-buf-sysfs-stats.h > > I don't know the dma-buf code at all, but from a sysfs/kobject point of > view, this patch looks good to me: > > Reviewed-by: Greg Kroah-Hartman Best, Sumit.