Date:   Thu, 22 Apr 2021 14:08:51 +0000
From:   <Peter.Enderborg@...y.com>
To:     <rppt@...nel.org>
CC:     <linux-kernel@...r.kernel.org>, <linux-fsdevel@...r.kernel.org>,
        <sumit.semwal@...aro.org>, <christian.koenig@....com>,
        <adobriyan@...il.com>, <akpm@...ux-foundation.org>,
        <songmuchun@...edance.com>, <guro@...com>, <shakeelb@...gle.com>,
        <mhocko@...e.com>, <neilb@...e.de>, <samitolvanen@...gle.com>,
        <linux-media@...r.kernel.org>, <dri-devel@...ts.freedesktop.org>,
        <linaro-mm-sig@...ts.linaro.org>, <willy@...radead.org>
Subject: Re: [PATCH v5] dma-buf: Add DmaBufTotal counter in meminfo

On 4/22/21 10:06 AM, Mike Rapoport wrote:
> On Wed, Apr 21, 2021 at 05:35:57PM +0000, Peter.Enderborg@...y.com wrote:
>> On 4/21/21 5:31 PM, Mike Rapoport wrote:
>>> On Wed, Apr 21, 2021 at 10:37:11AM +0000, Peter.Enderborg@...y.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 kernel
>>>>> code, but in terms of semantics. Like if userspace allocates a GL texture,
>>>>> 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 what
>>>>
>>>> you pointing at to know what it is. it might be a hardware or a other pointer.
>>>>
>>>> If there is a limitation on your pointers it is a good metric to count them
>>>> even if you don't  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.  We have the detailed in debugfs, but nothing
>>>> 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.
>> Thanks!
>>
>>
>>> 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?
>> Android is using it for binder that connect more or less everything
>> internally.
>  
> Ok, then it rules out /sys/class/graphics indeed.
>
>>> * 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?
>> When you turn on developer mode on android you can use
>> usb with a program called adb. And there you get a normal shell.
>>
>> (not root though)
>>
>> There is applications that non developers can use to get
>> information. It is very limited though and there are API's
>> provide it.
>>
>>
>>> * 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?
>>>
>> When you debug thousands of devices it is quite nice to have
>> ways to classify what the problem it is not. The normal user does not
>> see anything of this. However they can generate bug-reports that
>> collect information about as much they can. Then the user have
>> to provide this bug-report to the manufacture or mostly the
>> application developer. And when the problem is
>> system related we need to reproduce the issue on a full
>> debug enabled unit.
> So the flow is like this:
>
> * a user has a problem and reports it to an application developer; at best
>   the user runs simple and limited app to collect some data
> * if the application developer considers this issue as a system related
>   they can open adb and collect some more information about the system
>   using non-root shell with selinux policy restrictions and send this
>   information to the device manufacturer.
> * the manufacturer continues to debug the issue and at this point as much
>   information is possible would have been useful.
>
> In this flow I still fail to understand why the manufacturer cannot provide
> userspace tools that will be able to collect the required information.
> These tools not necessarily need to target the end user, they may be only
> intended for the application developers, e.g. policy could allow such tool
> to access some of the system data only when the system is in developer
> mode.
>
The manufacture is trying to get the tool to work. This is what the
patch is about. Even for a application developer a commercial
phone is locked down. Many vendors allow that you flash
some other software like a AOSP.  But that can be very
different. Like installing a ubuntu on a PC to debug a Fedora issue.

And sure we can pickup parts of what using the dma-buf. But
we can not get the total and be sure that is the total without a
proper counter.

Powered by blists - more mailing lists