Re: [Linaro-mm-sig] [PATCH v3] dmabuf: Add the capability to expose DMA-BUF stats in sysfs
On Thu, Feb 4, 2021 at 9:13 AM Christian König wrote: > > Am 03.02.21 um 21:14 schrieb Hridya Valsaraju: > > On Wed, Feb 3, 2021 at 2:25 AM Daniel Vetter wrote: > >> On Mon, Feb 01, 2021 at 01:02:30PM -0800, Hridya Valsaraju wrote: > >>> On Mon, Feb 1, 2021 at 10:37 AM Daniel Vetter wrote: > On Thu, Jan 28, 2021 at 1:03 PM Sumit Semwal > wrote: > > On Thu, 28 Jan 2021 at 17:23, Christian König > > wrote: > >> Am 28.01.21 um 12:00 schrieb Sumit Semwal: > >>> 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//device > > /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 > > creating > > 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önig. > > > > [1]: > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fpatchwork%2Fpatch%2F1088791%2Fdata=04%7C01%7Cchristian.koenig%40amd.com%7C32ff828b838e44b1de6f08d8c8805913%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637479800886768855%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=imVoJbadV221%2F6u32diSyEICLk7WUNakz8G742RPSaA%3Dreserved=0 > > [2]: > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fandroid-review.googlesource.com%2Fq%2Ftopic%3A%2522dmabuf-sysfs%2522data=04%7C01%7Cchristian.koenig%40amd.com%7C32ff828b838e44b1de6f08d8c8805913%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637479800886778838%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=X78MH6IvdcE1mGMngrVdBYooi93vpjvfLU9kQHjZyKo%3Dreserved=0+(status:open%20OR%20status:merged) > > [3]: > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fandroid-review.googlesource.com%2Fc%2Fplatform%2Fsystem%2Fmemory%2Flibmeminfo%2F%2B%2F1549734data=04%7C01%7Cchristian.koenig%40amd.com%7C32ff828b838e44b1de6f08d8c8805913%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637479800886778838%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=JH7m5yspXKDqVX5DB380cnU4kWNSyh6ctDaphJvOyw8%3Dreserved=0 > > > > 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
Re: [Linaro-mm-sig] [PATCH v3] dmabuf: Add the capability to expose DMA-BUF stats in sysfs
Am 03.02.21 um 21:14 schrieb Hridya Valsaraju: On Wed, Feb 3, 2021 at 2:25 AM Daniel Vetter wrote: On Mon, Feb 01, 2021 at 01:02:30PM -0800, Hridya Valsaraju wrote: On Mon, Feb 1, 2021 at 10:37 AM Daniel Vetter wrote: On Thu, Jan 28, 2021 at 1:03 PM Sumit Semwal wrote: On Thu, 28 Jan 2021 at 17:23, Christian König wrote: Am 28.01.21 um 12:00 schrieb Sumit Semwal: 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//device /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 creating 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önig. [1]: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fpatchwork%2Fpatch%2F1088791%2Fdata=04%7C01%7Cchristian.koenig%40amd.com%7C32ff828b838e44b1de6f08d8c8805913%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637479800886768855%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=imVoJbadV221%2F6u32diSyEICLk7WUNakz8G742RPSaA%3Dreserved=0 [2]: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fandroid-review.googlesource.com%2Fq%2Ftopic%3A%2522dmabuf-sysfs%2522data=04%7C01%7Cchristian.koenig%40amd.com%7C32ff828b838e44b1de6f08d8c8805913%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637479800886778838%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=X78MH6IvdcE1mGMngrVdBYooi93vpjvfLU9kQHjZyKo%3Dreserved=0+(status:open%20OR%20status:merged) [3]: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fandroid-review.googlesource.com%2Fc%2Fplatform%2Fsystem%2Fmemory%2Flibmeminfo%2F%2B%2F1549734data=04%7C01%7Cchristian.koenig%40amd.com%7C32ff828b838e44b1de6f08d8c8805913%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637479800886778838%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=JH7m5yspXKDqVX5DB380cnU4kWNSyh6ctDaphJvOyw8%3Dreserved=0 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! From the technical side it looks clean to me, feel free to add my acked-by while pushing. But I would at least try to convince Daniel on the design. At least some of his concerns seems to be valid and keep in mind that we need to support this interface forever. Naturally. Since he didn't comment over Hridya's last clarification about the tracepoints to track total GPU memory allocations being orthogonal to this series, I assumed he agreed with it. The tracepoint being orthogonal didn't really look convincing to me, since I do expect we'll need that at a much more generic level, at allocators. Whether that's dma-buf heaps or in drm or wherever. And we probably also need that to somehow align with cgroups accounting. But I guess for this it should be easy to extend however we see fit, so retrofitting allocator sources and anything else we want/need for the overall gpu memory
Re: [Linaro-mm-sig] [PATCH v3] dmabuf: Add the capability to expose DMA-BUF stats in sysfs
On Wed, Feb 3, 2021 at 2:25 AM Daniel Vetter wrote: > > On Mon, Feb 01, 2021 at 01:02:30PM -0800, Hridya Valsaraju wrote: > > On Mon, Feb 1, 2021 at 10:37 AM Daniel Vetter wrote: > > > > > > On Thu, Jan 28, 2021 at 1:03 PM Sumit Semwal > > > wrote: > > > > > > > > On Thu, 28 Jan 2021 at 17:23, Christian König > > > > wrote: > > > > > > > > > > Am 28.01.21 um 12:00 schrieb Sumit Semwal: > > > > > > 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//device > > > > > >>> /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 > > > > > >>> creating > > > > > >>> 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önig. > > > > > >>> > > > > > >>> [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/libmeminfo/+/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! > > > > > > > > > > From the technical side it looks clean to me, feel free to add my > > > > > acked-by while pushing. > > > > > > > > > > But I would at least try to convince Daniel on the design. At least > > > > > some > > > > > of his concerns seems to be valid and keep in mind that we need to > > > > > support this interface forever. > > > > > > > > Naturally. > > > > > > > > Since he didn't comment over Hridya's last clarification about the > > > > tracepoints to track total GPU memory allocations being orthogonal to > > > > this series, I assumed he agreed with it. > > > > > > The tracepoint being orthogonal didn't really look convincing to me, > > > since I do expect we'll need that at a much more generic level, at > > > allocators. Whether that's dma-buf heaps or in drm or wherever. And we > > > probably also need that to somehow align with cgroups accounting. > > > > > > But I guess for this it should be
Re: [Linaro-mm-sig] [PATCH v3] dmabuf: Add the capability to expose DMA-BUF stats in sysfs
On Mon, Feb 01, 2021 at 01:02:30PM -0800, Hridya Valsaraju wrote: > On Mon, Feb 1, 2021 at 10:37 AM Daniel Vetter wrote: > > > > On Thu, Jan 28, 2021 at 1:03 PM Sumit Semwal > > wrote: > > > > > > On Thu, 28 Jan 2021 at 17:23, Christian König > > > wrote: > > > > > > > > Am 28.01.21 um 12:00 schrieb Sumit Semwal: > > > > > 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//device > > > > >>> /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 > > > > >>> creating > > > > >>> 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önig. > > > > >>> > > > > >>> [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/libmeminfo/+/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! > > > > > > > > From the technical side it looks clean to me, feel free to add my > > > > acked-by while pushing. > > > > > > > > But I would at least try to convince Daniel on the design. At least some > > > > of his concerns seems to be valid and keep in mind that we need to > > > > support this interface forever. > > > > > > Naturally. > > > > > > Since he didn't comment over Hridya's last clarification about the > > > tracepoints to track total GPU memory allocations being orthogonal to > > > this series, I assumed he agreed with it. > > > > The tracepoint being orthogonal didn't really look convincing to me, > > since I do expect we'll need that at a much more generic level, at > > allocators. Whether that's dma-buf heaps or in drm or wherever. And we > > probably also need that to somehow align with cgroups accounting. > > > > But I guess for this it should be easy to extend however we see fit, > > so retrofitting allocator sources and anything else we want/need for > > the overall gpu memory account shouldn't be a problem. Also, it's > > first, so the proof for showing it all works together is more on the > > tracepoints :-) > > > > > Daniel, do you still have objections around adding this patch in?
Re: [Linaro-mm-sig] [PATCH v3] dmabuf: Add the capability to expose DMA-BUF stats in sysfs
On Mon, Feb 1, 2021 at 10:37 AM Daniel Vetter wrote: > > On Thu, Jan 28, 2021 at 1:03 PM Sumit Semwal wrote: > > > > On Thu, 28 Jan 2021 at 17:23, Christian König > > wrote: > > > > > > Am 28.01.21 um 12:00 schrieb Sumit Semwal: > > > > 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//device > > > >>> /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 > > > >>> creating > > > >>> 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önig. > > > >>> > > > >>> [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/libmeminfo/+/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! > > > > > > From the technical side it looks clean to me, feel free to add my > > > acked-by while pushing. > > > > > > But I would at least try to convince Daniel on the design. At least some > > > of his concerns seems to be valid and keep in mind that we need to > > > support this interface forever. > > > > Naturally. > > > > Since he didn't comment over Hridya's last clarification about the > > tracepoints to track total GPU memory allocations being orthogonal to > > this series, I assumed he agreed with it. > > The tracepoint being orthogonal didn't really look convincing to me, > since I do expect we'll need that at a much more generic level, at > allocators. Whether that's dma-buf heaps or in drm or wherever. And we > probably also need that to somehow align with cgroups accounting. > > But I guess for this it should be easy to extend however we see fit, > so retrofitting allocator sources and anything else we want/need for > the overall gpu memory account shouldn't be a problem. Also, it's > first, so the proof for showing it all works together is more on the > tracepoints :-) > > > Daniel, do you still have objections around adding this patch in? > > Needs docs (especially the uapi I think would be useful to document), > igt tests, that kind of stuff still I think? It's meant to be generic > uapi across drivers, generally we're a pile stricter for that (and yes > dma-buf heaps I think didn't do all that, so maybe there's an argument > for doing this a bit more sloppy or at
Re: [Linaro-mm-sig] [PATCH v3] dmabuf: Add the capability to expose DMA-BUF stats in sysfs
On Thu, Jan 28, 2021 at 1:03 PM Sumit Semwal wrote: > > On Thu, 28 Jan 2021 at 17:23, Christian König > wrote: > > > > Am 28.01.21 um 12:00 schrieb Sumit Semwal: > > > 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//device > > >>> /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 creating > > >>> 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önig. > > >>> > > >>> [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/libmeminfo/+/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! > > > > From the technical side it looks clean to me, feel free to add my > > acked-by while pushing. > > > > But I would at least try to convince Daniel on the design. At least some > > of his concerns seems to be valid and keep in mind that we need to > > support this interface forever. > > Naturally. > > Since he didn't comment over Hridya's last clarification about the > tracepoints to track total GPU memory allocations being orthogonal to > this series, I assumed he agreed with it. The tracepoint being orthogonal didn't really look convincing to me, since I do expect we'll need that at a much more generic level, at allocators. Whether that's dma-buf heaps or in drm or wherever. And we probably also need that to somehow align with cgroups accounting. But I guess for this it should be easy to extend however we see fit, so retrofitting allocator sources and anything else we want/need for the overall gpu memory account shouldn't be a problem. Also, it's first, so the proof for showing it all works together is more on the tracepoints :-) > Daniel, do you still have objections around adding this patch in? Needs docs (especially the uapi I think would be useful to document), igt tests, that kind of stuff still I think? It's meant to be generic uapi across drivers, generally we're a pile stricter for that (and yes dma-buf heaps I think didn't do all that, so maybe there's an argument for doing this a bit more sloppy or at least "the testsuite is somewhere else"). But I think it would be good to have this all done. -Daniel > > > > > Regards, > > Christian. > > Best, > Sumit. > > > > > > > >>> --- > > >>> Changes in v3: > > >>> Fix a warning reported by the kernel test robot. > > >>> > > >>> Changes in v2: > > >>>
Re: [Linaro-mm-sig] [PATCH v3] dmabuf: Add the capability to expose DMA-BUF stats in sysfs
On Thu, Jan 28, 2021 at 6:35 AM Sumit Semwal wrote: > > Hi Simon, > > On Thu, 28 Jan 2021 at 20:01, Simon Ser wrote: > > > > On Thursday, January 28th, 2021 at 1:03 PM, Sumit Semwal > > wrote: > > > > > Since he didn't comment over Hridya's last clarification about the > > > tracepoints to track total GPU memory allocations being orthogonal to > > > this series, I assumed he agreed with it. > > > > IIRC he's away this week. (I don't remember when he comes back.) > > > > > Daniel, do you still have objections around adding this patch in? > > > > (Adding him explicitly in CC) > Thanks for doing this! > > Best, > Sumit. Thank you all for the help :) Regards, Hridya
Re: [Linaro-mm-sig] [PATCH v3] dmabuf: Add the capability to expose DMA-BUF stats in sysfs
Hi Simon, On Thu, 28 Jan 2021 at 20:01, Simon Ser wrote: > > On Thursday, January 28th, 2021 at 1:03 PM, Sumit Semwal > wrote: > > > Since he didn't comment over Hridya's last clarification about the > > tracepoints to track total GPU memory allocations being orthogonal to > > this series, I assumed he agreed with it. > > IIRC he's away this week. (I don't remember when he comes back.) > > > Daniel, do you still have objections around adding this patch in? > > (Adding him explicitly in CC) Thanks for doing this! Best, Sumit.
Re: [Linaro-mm-sig] [PATCH v3] dmabuf: Add the capability to expose DMA-BUF stats in sysfs
On Thursday, January 28th, 2021 at 1:03 PM, Sumit Semwal wrote: > Since he didn't comment over Hridya's last clarification about the > tracepoints to track total GPU memory allocations being orthogonal to > this series, I assumed he agreed with it. IIRC he's away this week. (I don't remember when he comes back.) > Daniel, do you still have objections around adding this patch in? (Adding him explicitly in CC)
Re: [Linaro-mm-sig] [PATCH v3] dmabuf: Add the capability to expose DMA-BUF stats in sysfs
On Thu, 28 Jan 2021 at 17:23, Christian König wrote: > > Am 28.01.21 um 12:00 schrieb Sumit Semwal: > > 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//device > >>> /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 creating > >>> 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önig. > >>> > >>> [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/libmeminfo/+/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! > > From the technical side it looks clean to me, feel free to add my > acked-by while pushing. > > But I would at least try to convince Daniel on the design. At least some > of his concerns seems to be valid and keep in mind that we need to > support this interface forever. Naturally. Since he didn't comment over Hridya's last clarification about the tracepoints to track total GPU memory allocations being orthogonal to this series, I assumed he agreed with it. Daniel, do you still have objections around adding this patch in? > > Regards, > Christian. Best, Sumit. > > > > >>> --- > >>> 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 addition > >>> 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 as > >>> symlinks and to introduce map_count as a separate file. Based on > >>> feedback from Daniel Vetter and Christian König. 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-buffers > >>> create mode 100644 drivers/dma-buf/dma-buf-sysfs-stats.c > >>> create mode 100644 drivers/dma-buf/dma-buf-sysfs-stats.h > >>
Re: [Linaro-mm-sig] [PATCH v3] dmabuf: Add the capability to expose DMA-BUF stats in sysfs
Am 28.01.21 um 12:00 schrieb Sumit Semwal: 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//device /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 creating 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önig. [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/libmeminfo/+/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! From the technical side it looks clean to me, feel free to add my acked-by while pushing. But I would at least try to convince Daniel on the design. At least some of his concerns seems to be valid and keep in mind that we need to support this interface forever. Regards, Christian. --- 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 addition 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 as symlinks and to introduce map_count as a separate file. Based on feedback from Daniel Vetter and Christian König. 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-buffers 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. ___ Linaro-mm-sig mailing list linaro-mm-...@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-mm-sig
Re: [PATCH v3] dmabuf: Add the capability to expose DMA-BUF stats in sysfs
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//device > > /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 creating > > 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önig. > > > > [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/libmeminfo/+/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 addition > > 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 as > > symlinks and to introduce map_count as a separate file. Based on > > feedback from Daniel Vetter and Christian König. 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-buffers > > 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.
Re: [PATCH v3] dmabuf: Add the capability to expose DMA-BUF stats in sysfs
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//device > /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 creating > 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önig. > > [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/libmeminfo/+/1549734 > > Signed-off-by: Hridya Valsaraju > Reported-by: kernel test robot > --- > 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 addition > 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 as > symlinks and to introduce map_count as a separate file. Based on > feedback from Daniel Vetter and Christian König. 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-buffers > 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
[PATCH v3] dmabuf: Add the capability to expose DMA-BUF stats in sysfs
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//device /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 creating 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önig. [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/libmeminfo/+/1549734 Signed-off-by: Hridya Valsaraju Reported-by: kernel test robot --- 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 addition 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 as symlinks and to introduce map_count as a separate file. Based on feedback from Daniel Vetter and Christian König. 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-buffers create mode 100644 drivers/dma-buf/dma-buf-sysfs-stats.c create mode 100644 drivers/dma-buf/dma-buf-sysfs-stats.h diff --git a/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers b/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers new file mode 100644 index ..6f7c65209f07 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers @@ -0,0 +1,52 @@ +What: /sys/kernel/dmabuf/buffers +Date: January 2021 +KernelVersion: v5.12 +Contact: Hridya Valsaraju +Description: The /sys/kernel/dmabuf/buffers directory contains a + snapshot of the internal state of every DMA-BUF. + /sys/kernel/dmabuf/buffers/ will contain the + statistics for the DMA-BUF with the unique inode number + +Users: kernel memory tuning/debugging tools + +What: /sys/kernel/dmabuf/buffers//exporter_name +Date: January 2021 +KernelVersion: v5.12 +Contact: Hridya Valsaraju +Description: This file is read-only and contains the name of the exporter of + the DMA-BUF. + +What: /sys/kernel/dmabuf/buffers//size +Date: January 2021 +KernelVersion: v5.12 +Contact: Hridya Valsaraju +Description: This file is read-only and specifies the size of the DMA-BUF in + bytes. + +What: /sys/kernel/dmabuf/buffers//attachments +Date: January 2021 +KernelVersion: v5.12 +Contact: Hridya Valsaraju +Description: This directory will contain subdirectories representing every + attachment of the DMA-BUF. + +What: /sys/kernel/dmabuf/buffers//attachments/ +Date: January 2021
