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=-3.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 E087FC43460 for ; Wed, 21 Apr 2021 15:32:13 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8EE6461428 for ; Wed, 21 Apr 2021 15:32:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8EE6461428 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id CB8BB6E9C8; Wed, 21 Apr 2021 15:32:12 +0000 (UTC) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by gabe.freedesktop.org (Postfix) with ESMTPS id 21F166E9B8 for ; Wed, 21 Apr 2021 15:32:11 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id F277861445; Wed, 21 Apr 2021 15:32:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1619019129; bh=RC899umZ0BwpHoFBaQEd03wqXFYBjtGaL5NqM7dfCT8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=CpNQszCLq4n8vEbp+4q9qxxt6foYHXA6LMbxM0pUASXfc28rRQcnHijjCXk/bU4TR TdDYeNqRAnnuj8/VLcS5qJ+U07HSMDxPsyQDrG7EJzs2PCv4MxVSBtSYtwYW+PNk62 KPitZe+vN9l/HeCKZkA695LuhNegPcRtu6FLyojANSpA0XhVRnYVDfv4MxiPKnPyaa s33u6+4RK9KDcho9/4XcQ0uBmY7Nh+0+l0fdoIHE8WzrDzLSrBN5K5PIpOTmbJh780 NBpCEJ2w2VdcFapAACBUQ6BQdb5B+z9QC/dLgLEdzQHHEZlz953zvRL+EwG6ghuB8k P/eYtCOFPaOGg== Date: Wed, 21 Apr 2021 18:31:58 +0300 From: Mike Rapoport To: Peter.Enderborg@sony.com Subject: Re: [PATCH v5] dma-buf: Add DmaBufTotal counter in meminfo Message-ID: References: <20210417163835.25064-1-peter.enderborg@sony.com> <176e7e71-59b7-b288-9483-10e0f42a7a3f@sony.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: mhocko@suse.com, neilb@suse.de, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, adobriyan@gmail.com, linaro-mm-sig@lists.linaro.org, shakeelb@google.com, willy@infradead.org, samitolvanen@google.com, songmuchun@bytedance.com, linux-fsdevel@vger.kernel.org, akpm@linux-foundation.org, christian.koenig@amd.com, guro@fb.com, linux-media@vger.kernel.org Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Wed, Apr 21, 2021 at 10:37:11AM +0000, Peter.Enderborg@sony.com wrote: > On 4/21/21 11:15 AM, Daniel Vetter wrote: > > > > We need to understand what the "correct" value is. Not in terms of kern= el > > code, but in terms of semantics. Like if userspace allocates a GL textu= re, > > is this supposed to show up in your metric or not. Stuff like that. > That it like that would like to only one pointer type. You need to know w= hat > = > you pointing at to know what it is. it might be a hardware or a other poi= nter. > = > If there is a limitation on your pointers it is a good metric to count th= em > even if you don't=A0 know what they are. Same goes for dma-buf, they > are generic, but they consume some resources that are counted in pages. > = > It would be very good if there a sub division where you could measure > all possible types separately.=A0 We have the detailed in debugfs, but no= thing > for the user. A summary in meminfo seems to be the best place for such > metric. = Let me try to summarize my understanding of the problem, maybe it'll help others as well. A device driver allocates memory and exports this memory via dma-buf so that this memory will be accessible for userspace via a file descriptor. The allocated memory can be either allocated with alloc_page() from system RAM or by other means from dedicated VRAM (that is not managed by Linux mm) or even from on-device memory. The dma-buf driver tracks the amount of the memory it was requested to export and the size it sees is available at debugfs and fdinfo. The debugfs is not available to user and maybe entirely disabled in production systems. There could be quite a few open dma-bufs so there is no overall summary, plus fdinfo in production systems your refer to is also unavailable to the user because of selinux policy. And there are a few details that are not clear to me: * Since DRM device drivers seem to be the major user of dma-buf exports, why cannot we add information about their memory consumption to, say, /sys/class/graphics/drm/cardX/memory-usage? * How exactly user generates reports that would include the new counters? From my (mostly outdated) experience Android users won't open a terminal and type 'cat /proc/meminfo' there. I'd presume there is a vendor agent that collects the data and sends it for analysis. In this case what is the reason the vendor is unable to adjust selinix policy so that the agent will be able to access fdinfo? * And, as others already mentioned, it is not clear what are the problems that can be detected by examining DmaBufTotal except saying "oh, there is too much/too little memory exported via dma-buf". What would be user visible effects of these problems? What are the next steps to investigate them? What other data will be probably required to identify root cause? -- = Sincerely yours, Mike. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel