| Message ID | 20210126204240.418297-1-hridya@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v3] dmabuf: Add the capability to expose DMA-BUF stats in sysfs | expand |
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/<inode_number>/exporter_name > /sys/kernel/dmabuf/buffers/<inode_number>/size > /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attach_uid>/device > /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attach_uid>/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 <hridya@google.com> > Reported-by: kernel test robot <lkp@intel.com> > --- > 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 <gregkh@linuxfoundation.org>
Hi Hridya, On Wed, 27 Jan 2021 at 17:36, Greg KH <gregkh@linuxfoundation.org> 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/<inode_number>/exporter_name > > /sys/kernel/dmabuf/buffers/<inode_number>/size > > /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attach_uid>/device > > /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attach_uid>/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 <hridya@google.com> > > Reported-by: kernel test robot <lkp@intel.com> 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 <gregkh@linuxfoundation.org> Best, Sumit.
Am 28.01.21 um 12:00 schrieb Sumit Semwal: > Hi Hridya, > > On Wed, 27 Jan 2021 at 17:36, Greg KH <gregkh@linuxfoundation.org> 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/<inode_number>/exporter_name >>> /sys/kernel/dmabuf/buffers/<inode_number>/size >>> /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attach_uid>/device >>> /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attach_uid>/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 <hridya@google.com> >>> Reported-by: kernel test robot <lkp@intel.com> > 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 <gregkh@linuxfoundation.org> > Best, > Sumit. > _______________________________________________ > Linaro-mm-sig mailing list > Linaro-mm-sig@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/linaro-mm-sig
On Thu, 28 Jan 2021 at 17:23, Christian König <ckoenig.leichtzumerken@gmail.com> wrote: > > Am 28.01.21 um 12:00 schrieb Sumit Semwal: > > Hi Hridya, > > > > On Wed, 27 Jan 2021 at 17:36, Greg KH <gregkh@linuxfoundation.org> 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/<inode_number>/exporter_name > >>> /sys/kernel/dmabuf/buffers/<inode_number>/size > >>> /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attach_uid>/device > >>> /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attach_uid>/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 <hridya@google.com> > >>> Reported-by: kernel test robot <lkp@intel.com> > > 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 > >> 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 <gregkh@linuxfoundation.org> > > Best, > > Sumit. > > _______________________________________________ > > Linaro-mm-sig mailing list > > Linaro-mm-sig@lists.linaro.org > > https://lists.linaro.org/mailman/listinfo/linaro-mm-sig > -- Thanks and regards, Sumit Semwal Linaro Consumer Group - Tech Lead Linaro.org │ Open source software for ARM SoCs
On Thursday, January 28th, 2021 at 1:03 PM, Sumit Semwal <sumit.semwal@linaro.org> 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)
Hi Simon, On Thu, 28 Jan 2021 at 20:01, Simon Ser <contact@emersion.fr> wrote: > > On Thursday, January 28th, 2021 at 1:03 PM, Sumit Semwal <sumit.semwal@linaro.org> 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.
On Thu, Jan 28, 2021 at 6:35 AM Sumit Semwal <sumit.semwal@linaro.org> wrote: > > Hi Simon, > > On Thu, 28 Jan 2021 at 20:01, Simon Ser <contact@emersion.fr> wrote: > > > > On Thursday, January 28th, 2021 at 1:03 PM, Sumit Semwal <sumit.semwal@linaro.org> 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
On Thu, Jan 28, 2021 at 1:03 PM Sumit Semwal <sumit.semwal@linaro.org> wrote: > > On Thu, 28 Jan 2021 at 17:23, Christian König > <ckoenig.leichtzumerken@gmail.com> wrote: > > > > Am 28.01.21 um 12:00 schrieb Sumit Semwal: > > > Hi Hridya, > > > > > > On Wed, 27 Jan 2021 at 17:36, Greg KH <gregkh@linuxfoundation.org> 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/<inode_number>/exporter_name > > >>> /sys/kernel/dmabuf/buffers/<inode_number>/size > > >>> /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attach_uid>/device > > >>> /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attach_uid>/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 <hridya@google.com> > > >>> Reported-by: kernel test robot <lkp@intel.com> > > > 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: > > >>> -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 <gregkh@linuxfoundation.org> > > > Best, > > > Sumit. > > > _______________________________________________ > > > Linaro-mm-sig mailing list > > > Linaro-mm-sig@lists.linaro.org > > > https://lists.linaro.org/mailman/listinfo/linaro-mm-sig > > > > > -- > Thanks and regards, > > Sumit Semwal > Linaro Consumer Group - Tech Lead > Linaro.org │ Open source software for ARM SoCs > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Mon, Feb 1, 2021 at 10:37 AM Daniel Vetter <daniel@ffwll.ch> wrote: > > On Thu, Jan 28, 2021 at 1:03 PM Sumit Semwal <sumit.semwal@linaro.org> wrote: > > > > On Thu, 28 Jan 2021 at 17:23, Christian König > > <ckoenig.leichtzumerken@gmail.com> wrote: > > > > > > Am 28.01.21 um 12:00 schrieb Sumit Semwal: > > > > Hi Hridya, > > > > > > > > On Wed, 27 Jan 2021 at 17:36, Greg KH <gregkh@linuxfoundation.org> 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/<inode_number>/exporter_name > > > >>> /sys/kernel/dmabuf/buffers/<inode_number>/size > > > >>> /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attach_uid>/device > > > >>> /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attach_uid>/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 <hridya@google.com> > > > >>> Reported-by: kernel test robot <lkp@intel.com> > > > > 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"). Thank you for taking another look Daniel! I will try adding an IGT test for the sysfs files. Other than the documentation in Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers(included in the patch), is there another place you would like to see the documentation copied to? Regards, Hridya > > 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: > > > >>> -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 <gregkh@linuxfoundation.org> > > > > Best, > > > > Sumit. > > > > _______________________________________________ > > > > Linaro-mm-sig mailing list > > > > Linaro-mm-sig@lists.linaro.org > > > > https://lists.linaro.org/mailman/listinfo/linaro-mm-sig > > > > > > > > > -- > > Thanks and regards, > > > > Sumit Semwal > > Linaro Consumer Group - Tech Lead > > Linaro.org │ Open source software for ARM SoCs > > _______________________________________________ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch
On Mon, Feb 01, 2021 at 01:02:30PM -0800, Hridya Valsaraju wrote: > On Mon, Feb 1, 2021 at 10:37 AM Daniel Vetter <daniel@ffwll.ch> wrote: > > > > On Thu, Jan 28, 2021 at 1:03 PM Sumit Semwal <sumit.semwal@linaro.org> wrote: > > > > > > On Thu, 28 Jan 2021 at 17:23, Christian König > > > <ckoenig.leichtzumerken@gmail.com> wrote: > > > > > > > > Am 28.01.21 um 12:00 schrieb Sumit Semwal: > > > > > Hi Hridya, > > > > > > > > > > On Wed, 27 Jan 2021 at 17:36, Greg KH <gregkh@linuxfoundation.org> 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/<inode_number>/exporter_name > > > > >>> /sys/kernel/dmabuf/buffers/<inode_number>/size > > > > >>> /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attach_uid>/device > > > > >>> /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attach_uid>/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 <hridya@google.com> > > > > >>> Reported-by: kernel test robot <lkp@intel.com> > > > > > 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"). > > Thank you for taking another look Daniel! > > I will try adding an IGT test for the sysfs files. Other than the > documentation in > Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers(included in the > patch), is there another place you would like to see the documentation > copied to? So just read the other thread, and sounds like Christian König brought up a solid concern with dma-buf fds generally not staying around for much. So I'm leaning more towards "this sounds like it's going to be useful for Android only, nothing else" concern. -Daniel > > Regards, > Hridya > > > > > 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: > > > > >>> -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 <gregkh@linuxfoundation.org> > > > > > Best, > > > > > Sumit. > > > > > _______________________________________________ > > > > > Linaro-mm-sig mailing list > > > > > Linaro-mm-sig@lists.linaro.org > > > > > https://lists.linaro.org/mailman/listinfo/linaro-mm-sig > > > > > > > > > > > > > -- > > > Thanks and regards, > > > > > > Sumit Semwal > > > Linaro Consumer Group - Tech Lead > > > Linaro.org │ Open source software for ARM SoCs > > > _______________________________________________ > > > dri-devel mailing list > > > dri-devel@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch
On Wed, Feb 3, 2021 at 2:25 AM Daniel Vetter <daniel@ffwll.ch> 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 <daniel@ffwll.ch> wrote: > > > > > > On Thu, Jan 28, 2021 at 1:03 PM Sumit Semwal <sumit.semwal@linaro.org> wrote: > > > > > > > > On Thu, 28 Jan 2021 at 17:23, Christian König > > > > <ckoenig.leichtzumerken@gmail.com> wrote: > > > > > > > > > > Am 28.01.21 um 12:00 schrieb Sumit Semwal: > > > > > > Hi Hridya, > > > > > > > > > > > > On Wed, 27 Jan 2021 at 17:36, Greg KH <gregkh@linuxfoundation.org> 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/<inode_number>/exporter_name > > > > > >>> /sys/kernel/dmabuf/buffers/<inode_number>/size > > > > > >>> /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attach_uid>/device > > > > > >>> /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attach_uid>/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 <hridya@google.com> > > > > > >>> Reported-by: kernel test robot <lkp@intel.com> > > > > > > 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"). > > > > Thank you for taking another look Daniel! > > > > I will try adding an IGT test for the sysfs files. Other than the > > documentation in > > Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers(included in the > > patch), is there another place you would like to see the documentation > > copied to? > > So just read the other thread, and sounds like Christian König brought up > a solid concern with dma-buf fds generally not staying around for much. Thank you for the reply Daniel! Could you please elaborate on the connection with the other thread you mentioned? I am a little confused since this patch does not deal with tracking DMA-BUF fds. Regards, Hridya > > So I'm leaning more towards "this sounds like it's going to be useful for > Android only, nothing else" concern. > -Daniel > > > > > Regards, > > Hridya > > > > > > > > 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: > > > > > >>> -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 <gregkh@linuxfoundation.org> > > > > > > Best, > > > > > > Sumit. > > > > > > _______________________________________________ > > > > > > Linaro-mm-sig mailing list > > > > > > Linaro-mm-sig@lists.linaro.org > > > > > > https://lists.linaro.org/mailman/listinfo/linaro-mm-sig > > > > > > > > > > > > > > > > > -- > > > > Thanks and regards, > > > > > > > > Sumit Semwal > > > > Linaro Consumer Group - Tech Lead > > > > Linaro.org │ Open source software for ARM SoCs > > > > _______________________________________________ > > > > dri-devel mailing list > > > > dri-devel@lists.freedesktop.org > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > > > > > > > > > -- > > > Daniel Vetter > > > Software Engineer, Intel Corporation > > > http://blog.ffwll.ch > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch
Am 03.02.21 um 21:14 schrieb Hridya Valsaraju: > On Wed, Feb 3, 2021 at 2:25 AM Daniel Vetter <daniel@ffwll.ch> 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 <daniel@ffwll.ch> wrote: >>>> On Thu, Jan 28, 2021 at 1:03 PM Sumit Semwal <sumit.semwal@linaro.org> wrote: >>>>> On Thu, 28 Jan 2021 at 17:23, Christian König >>>>> <ckoenig.leichtzumerken@gmail.com> wrote: >>>>>> Am 28.01.21 um 12:00 schrieb Sumit Semwal: >>>>>>> Hi Hridya, >>>>>>> >>>>>>> On Wed, 27 Jan 2021 at 17:36, Greg KH <gregkh@linuxfoundation.org> 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/<inode_number>/exporter_name >>>>>>>>> /sys/kernel/dmabuf/buffers/<inode_number>/size >>>>>>>>> /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attach_uid>/device >>>>>>>>> /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attach_uid>/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%2F&data=04%7C01%7Cchristian.koenig%40amd.com%7C32ff828b838e44b1de6f08d8c8805913%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637479800886768855%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=imVoJbadV221%2F6u32diSyEICLk7WUNakz8G742RPSaA%3D&reserved=0 >>>>>>>>> [2]: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fandroid-review.googlesource.com%2Fq%2Ftopic%3A%2522dmabuf-sysfs%2522&data=04%7C01%7Cchristian.koenig%40amd.com%7C32ff828b838e44b1de6f08d8c8805913%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637479800886778838%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=X78MH6IvdcE1mGMngrVdBYooi93vpjvfLU9kQHjZyKo%3D&reserved=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%2F1549734&data=04%7C01%7Cchristian.koenig%40amd.com%7C32ff828b838e44b1de6f08d8c8805913%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637479800886778838%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=JH7m5yspXKDqVX5DB380cnU4kWNSyh6ctDaphJvOyw8%3D&reserved=0 >>>>>>>>> >>>>>>>>> Signed-off-by: Hridya Valsaraju <hridya@google.com> >>>>>>>>> Reported-by: kernel test robot <lkp@intel.com> >>>>>>> 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"). >>> Thank you for taking another look Daniel! >>> >>> I will try adding an IGT test for the sysfs files. Other than the >>> documentation in >>> Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers(included in the >>> patch), is there another place you would like to see the documentation >>> copied to? >> So just read the other thread, and sounds like Christian König brought up >> a solid concern with dma-buf fds generally not staying around for much. > Thank you for the reply Daniel! Could you please elaborate on the > connection with the other thread you mentioned? I am a little confused > since this patch does not deal with tracking DMA-BUF fds. In general DMA-buf fd are meant to be a temporary transport vehicle to interchange the data between processes. This here sounds like Android is using them as a long term reference. That is not necessary a good idea and causes multiple issues. On of those issues you try to address here, but Daniel is question now why do you have this problem in the first place? Regards, Christian. > > Regards, > Hridya > >> So I'm leaning more towards "this sounds like it's going to be useful for >> Android only, nothing else" concern. >> -Daniel >>
On Thu, Feb 4, 2021 at 9:13 AM Christian König <christian.koenig@amd.com> wrote: > > Am 03.02.21 um 21:14 schrieb Hridya Valsaraju: > > On Wed, Feb 3, 2021 at 2:25 AM Daniel Vetter <daniel@ffwll.ch> 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 <daniel@ffwll.ch> wrote: > >>>> On Thu, Jan 28, 2021 at 1:03 PM Sumit Semwal <sumit.semwal@linaro.org> wrote: > >>>>> On Thu, 28 Jan 2021 at 17:23, Christian König > >>>>> <ckoenig.leichtzumerken@gmail.com> wrote: > >>>>>> Am 28.01.21 um 12:00 schrieb Sumit Semwal: > >>>>>>> Hi Hridya, > >>>>>>> > >>>>>>> On Wed, 27 Jan 2021 at 17:36, Greg KH <gregkh@linuxfoundation.org> 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/<inode_number>/exporter_name > >>>>>>>>> /sys/kernel/dmabuf/buffers/<inode_number>/size > >>>>>>>>> /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attach_uid>/device > >>>>>>>>> /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attach_uid>/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%2F&data=04%7C01%7Cchristian.koenig%40amd.com%7C32ff828b838e44b1de6f08d8c8805913%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637479800886768855%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=imVoJbadV221%2F6u32diSyEICLk7WUNakz8G742RPSaA%3D&reserved=0 > >>>>>>>>> [2]: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fandroid-review.googlesource.com%2Fq%2Ftopic%3A%2522dmabuf-sysfs%2522&data=04%7C01%7Cchristian.koenig%40amd.com%7C32ff828b838e44b1de6f08d8c8805913%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637479800886778838%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=X78MH6IvdcE1mGMngrVdBYooi93vpjvfLU9kQHjZyKo%3D&reserved=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%2F1549734&data=04%7C01%7Cchristian.koenig%40amd.com%7C32ff828b838e44b1de6f08d8c8805913%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637479800886778838%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=JH7m5yspXKDqVX5DB380cnU4kWNSyh6ctDaphJvOyw8%3D&reserved=0 > >>>>>>>>> > >>>>>>>>> Signed-off-by: Hridya Valsaraju <hridya@google.com> > >>>>>>>>> Reported-by: kernel test robot <lkp@intel.com> > >>>>>>> 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"). > >>> Thank you for taking another look Daniel! > >>> > >>> I will try adding an IGT test for the sysfs files. Other than the > >>> documentation in > >>> Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers(included in the > >>> patch), is there another place you would like to see the documentation > >>> copied to? > >> So just read the other thread, and sounds like Christian König brought up > >> a solid concern with dma-buf fds generally not staying around for much. > > Thank you for the reply Daniel! Could you please elaborate on the > > connection with the other thread you mentioned? I am a little confused > > since this patch does not deal with tracking DMA-BUF fds. > > In general DMA-buf fd are meant to be a temporary transport vehicle to > interchange the data between processes. > > This here sounds like Android is using them as a long term reference. > That is not necessary a good idea and causes multiple issues. > > On of those issues you try to address here, but Daniel is question now > why do you have this problem in the first place? Afaik it's how Android works, lots more fd passing than we do (that's also why Android has sync_file, i.e. pass a sync fd around every frame, whereas we have drm_syncobj, i.e. pass the sync container object fd once around at startup and be done). I more meant that now I'm leaning more towards "we really need a unified *pu buffer reporting scheme" before signing up to something that only works for very limited use cases. The other thing that popped up is that between this patch, the virtio tracepoint there's now a 3rd patch from google Android to account xpu buffer memory in some cases (but only some, only partially). So really this gap-fillers here don't work, and we need something that really looks at the entire problem and figures out how to account that memory. Which is probably cgroups, but we'll see. I asked John to set up some meeting at least with the Android side so we can start to figure this out for real. -Daniel > > Regards, > Christian. > > > > > Regards, > > Hridya > > > >> So I'm leaning more towards "this sounds like it's going to be useful for > >> Android only, nothing else" concern. > >> -Daniel > >> >
diff --git a/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers b/Documentation/ABI/testing/sysfs-kernel-dmabuf-buffers new file mode 100644 index 000000000000..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 <hridya@google.com> +Description: The /sys/kernel/dmabuf/buffers directory contains a + snapshot of the internal state of every DMA-BUF. + /sys/kernel/dmabuf/buffers/<inode_number> will contain the + statistics for the DMA-BUF with the unique inode number + <inode_number> +Users: kernel memory tuning/debugging tools + +What: /sys/kernel/dmabuf/buffers/<inode_number>/exporter_name +Date: January 2021 +KernelVersion: v5.12 +Contact: Hridya Valsaraju <hridya@google.com> +Description: This file is read-only and contains the name of the exporter of + the DMA-BUF. + +What: /sys/kernel/dmabuf/buffers/<inode_number>/size +Date: January 2021 +KernelVersion: v5.12 +Contact: Hridya Valsaraju <hridya@google.com> +Description: This file is read-only and specifies the size of the DMA-BUF in + bytes. + +What: /sys/kernel/dmabuf/buffers/<inode_number>/attachments +Date: January 2021 +KernelVersion: v5.12 +Contact: Hridya Valsaraju <hridya@google.com> +Description: This directory will contain subdirectories representing every + attachment of the DMA-BUF. + +What: /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attachment_uid> +Date: January 2021 +KernelVersion: v5.12 +Contact: Hridya Valsaraju <hridya@google.com> +Description: This directory will contain information on the attaching device + and the number of current distinct device mappings. + +What: /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attachment_uid>/device +Date: January 2021 +KernelVersion: v5.12 +Contact: Hridya Valsaraju <hridya@google.com> +Description: This file is read-only and is a symlink to the attaching devices's + sysfs entry. + +What: /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attachment_uid>/map_counter +Date: January 2021 +KernelVersion: v5.12 +Contact: Hridya Valsaraju <hridya@google.com> +Description: This file is read-only and contains a map_counter indicating the + number of distinct device mappings of the attachment. diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig index 4f8224a6ac95..27e6a2dafeaa 100644 --- a/drivers/dma-buf/Kconfig +++ b/drivers/dma-buf/Kconfig @@ -64,6 +64,17 @@ menuconfig DMABUF_HEAPS allows userspace to allocate dma-bufs that can be shared between drivers. +menuconfig DMABUF_SYSFS_STATS + bool "DMA-BUF sysfs statistics" + select DMA_SHARED_BUFFER + help + Choose this option to enable DMA-BUF sysfs statistics + in location /sys/kernel/dmabuf/buffers. + + /sys/kernel/dmabuf/buffers/<inode_number> will contain + statistics for the DMA-BUF with the unique inode number + <inode_number>. + source "drivers/dma-buf/heaps/Kconfig" endmenu diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile index 995e05f609ff..40d81f23cacf 100644 --- a/drivers/dma-buf/Makefile +++ b/drivers/dma-buf/Makefile @@ -6,6 +6,7 @@ obj-$(CONFIG_DMABUF_HEAPS) += heaps/ obj-$(CONFIG_SYNC_FILE) += sync_file.o obj-$(CONFIG_SW_SYNC) += sw_sync.o sync_debug.o obj-$(CONFIG_UDMABUF) += udmabuf.o +obj-$(CONFIG_DMABUF_SYSFS_STATS) += dma-buf-sysfs-stats.o dmabuf_selftests-y := \ selftest.o \ diff --git a/drivers/dma-buf/dma-buf-sysfs-stats.c b/drivers/dma-buf/dma-buf-sysfs-stats.c new file mode 100644 index 000000000000..5dc2e17f3054 --- /dev/null +++ b/drivers/dma-buf/dma-buf-sysfs-stats.c @@ -0,0 +1,285 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * DMA-BUF sysfs statistics. + * + * Copyright (C) 2021 Google LLC. + */ + +#include <linux/dma-buf.h> +#include <linux/dma-resv.h> +#include <linux/kobject.h> +#include <linux/printk.h> +#include <linux/slab.h> +#include <linux/sysfs.h> + +#include "dma-buf-sysfs-stats.h" + +#define to_dma_buf_entry_from_kobj(x) container_of(x, struct dma_buf_sysfs_entry, kobj) + +struct dma_buf_stats_attribute { + struct attribute attr; + ssize_t (*show)(struct dma_buf *dmabuf, + struct dma_buf_stats_attribute *attr, char *buf); +}; +#define to_dma_buf_stats_attr(x) container_of(x, struct dma_buf_stats_attribute, attr) + +static ssize_t dma_buf_stats_attribute_show(struct kobject *kobj, + struct attribute *attr, + char *buf) +{ + struct dma_buf_stats_attribute *attribute; + struct dma_buf_sysfs_entry *sysfs_entry; + struct dma_buf *dmabuf; + + attribute = to_dma_buf_stats_attr(attr); + sysfs_entry = to_dma_buf_entry_from_kobj(kobj); + dmabuf = sysfs_entry->dmabuf; + + if (!dmabuf || !attribute->show) + return -EIO; + + return attribute->show(dmabuf, attribute, buf); +} + +static const struct sysfs_ops dma_buf_stats_sysfs_ops = { + .show = dma_buf_stats_attribute_show, +}; + +static ssize_t exporter_name_show(struct dma_buf *dmabuf, + struct dma_buf_stats_attribute *attr, + char *buf) +{ + return sysfs_emit(buf, "%s\n", dmabuf->exp_name); +} + +static ssize_t size_show(struct dma_buf *dmabuf, + struct dma_buf_stats_attribute *attr, + char *buf) +{ + return sysfs_emit(buf, "%zu\n", dmabuf->size); +} + +static struct dma_buf_stats_attribute exporter_name_attribute = + __ATTR_RO(exporter_name); +static struct dma_buf_stats_attribute size_attribute = __ATTR_RO(size); + +static struct attribute *dma_buf_stats_default_attrs[] = { + &exporter_name_attribute.attr, + &size_attribute.attr, + NULL, +}; +ATTRIBUTE_GROUPS(dma_buf_stats_default); + +static void dma_buf_sysfs_release(struct kobject *kobj) +{ + struct dma_buf_sysfs_entry *sysfs_entry; + + sysfs_entry = to_dma_buf_entry_from_kobj(kobj); + kfree(sysfs_entry); +} + +static struct kobj_type dma_buf_ktype = { + .sysfs_ops = &dma_buf_stats_sysfs_ops, + .release = dma_buf_sysfs_release, + .default_groups = dma_buf_stats_default_groups, +}; + +#define to_dma_buf_attach_entry_from_kobj(x) container_of(x, struct dma_buf_attach_sysfs_entry, kobj) + +struct dma_buf_attach_stats_attribute { + struct attribute attr; + ssize_t (*show)(struct dma_buf_attach_sysfs_entry *sysfs_entry, + struct dma_buf_attach_stats_attribute *attr, char *buf); +}; +#define to_dma_buf_attach_stats_attr(x) container_of(x, struct dma_buf_attach_stats_attribute, attr) + +static ssize_t dma_buf_attach_stats_attribute_show(struct kobject *kobj, + struct attribute *attr, + char *buf) +{ + struct dma_buf_attach_stats_attribute *attribute; + struct dma_buf_attach_sysfs_entry *sysfs_entry; + + attribute = to_dma_buf_attach_stats_attr(attr); + sysfs_entry = to_dma_buf_attach_entry_from_kobj(kobj); + + if (!attribute->show) + return -EIO; + + return attribute->show(sysfs_entry, attribute, buf); +} + +static const struct sysfs_ops dma_buf_attach_stats_sysfs_ops = { + .show = dma_buf_attach_stats_attribute_show, +}; + +static ssize_t map_counter_show(struct dma_buf_attach_sysfs_entry *sysfs_entry, + struct dma_buf_attach_stats_attribute *attr, + char *buf) +{ + return sysfs_emit(buf, "%u\n", sysfs_entry->map_counter); +} + +static struct dma_buf_attach_stats_attribute map_counter_attribute = + __ATTR_RO(map_counter); + +static struct attribute *dma_buf_attach_stats_default_attrs[] = { + &map_counter_attribute.attr, + NULL, +}; +ATTRIBUTE_GROUPS(dma_buf_attach_stats_default); + +static void dma_buf_attach_sysfs_release(struct kobject *kobj) +{ + struct dma_buf_attach_sysfs_entry *sysfs_entry; + + sysfs_entry = to_dma_buf_attach_entry_from_kobj(kobj); + kfree(sysfs_entry); +} + +static struct kobj_type dma_buf_attach_ktype = { + .sysfs_ops = &dma_buf_attach_stats_sysfs_ops, + .release = dma_buf_attach_sysfs_release, + .default_groups = dma_buf_attach_stats_default_groups, +}; + +void dma_buf_attach_stats_teardown(struct dma_buf_attachment *attach) +{ + struct dma_buf_attach_sysfs_entry *sysfs_entry; + + sysfs_entry = attach->sysfs_entry; + if (!sysfs_entry) + return; + + sysfs_delete_link(&sysfs_entry->kobj, &attach->dev->kobj, "device"); + + kobject_del(&sysfs_entry->kobj); + kobject_put(&sysfs_entry->kobj); +} + +int dma_buf_attach_stats_setup(struct dma_buf_attachment *attach, + unsigned int uid) +{ + struct dma_buf_attach_sysfs_entry *sysfs_entry; + int ret; + struct dma_buf *dmabuf; + + if (!attach) + return -EINVAL; + + dmabuf = attach->dmabuf; + + sysfs_entry = kzalloc(sizeof(struct dma_buf_attach_sysfs_entry), + GFP_KERNEL); + if (!sysfs_entry) + return -ENOMEM; + + sysfs_entry->kobj.kset = dmabuf->sysfs_entry->attach_stats_kset; + + attach->sysfs_entry = sysfs_entry; + + ret = kobject_init_and_add(&sysfs_entry->kobj, &dma_buf_attach_ktype, + NULL, "%u", uid); + if (ret) + goto kobj_err; + + ret = sysfs_create_link(&sysfs_entry->kobj, &attach->dev->kobj, + "device"); + if (ret) + goto link_err; + + return 0; + +link_err: + kobject_del(&sysfs_entry->kobj); +kobj_err: + kobject_put(&sysfs_entry->kobj); + attach->sysfs_entry = NULL; + + return ret; +} +void dma_buf_stats_teardown(struct dma_buf *dmabuf) +{ + struct dma_buf_sysfs_entry *sysfs_entry; + + sysfs_entry = dmabuf->sysfs_entry; + if (!sysfs_entry) + return; + + kset_unregister(sysfs_entry->attach_stats_kset); + kobject_del(&sysfs_entry->kobj); + kobject_put(&sysfs_entry->kobj); +} + +static struct kset *dma_buf_stats_kset; +static struct kset *dma_buf_per_buffer_stats_kset; +int dma_buf_init_sysfs_statistics(void) +{ + dma_buf_stats_kset = kset_create_and_add("dmabuf", NULL, kernel_kobj); + if (!dma_buf_stats_kset) + return -ENOMEM; + + dma_buf_per_buffer_stats_kset = kset_create_and_add("buffers", NULL, + &dma_buf_stats_kset->kobj); + if (!dma_buf_per_buffer_stats_kset) { + kset_unregister(dma_buf_stats_kset); + return -ENOMEM; + } + + return 0; +} + +void dma_buf_uninit_sysfs_statistics(void) +{ + kset_unregister(dma_buf_per_buffer_stats_kset); + kset_unregister(dma_buf_stats_kset); +} + +int dma_buf_stats_setup(struct dma_buf *dmabuf) +{ + struct dma_buf_sysfs_entry *sysfs_entry; + int ret; + struct kset *attach_stats_kset; + + if (!dmabuf || !dmabuf->file) + return -EINVAL; + + if (!dmabuf->exp_name) { + pr_err("exporter name must not be empty if stats needed\n"); + return -EINVAL; + } + + sysfs_entry = kzalloc(sizeof(struct dma_buf_sysfs_entry), GFP_KERNEL); + if (!sysfs_entry) + return -ENOMEM; + + sysfs_entry->kobj.kset = dma_buf_per_buffer_stats_kset; + sysfs_entry->dmabuf = dmabuf; + + dmabuf->sysfs_entry = sysfs_entry; + + /* create the directory for buffer stats */ + ret = kobject_init_and_add(&sysfs_entry->kobj, &dma_buf_ktype, NULL, + "%lu", file_inode(dmabuf->file)->i_ino); + if (ret) + goto err_sysfs_dmabuf; + + /* create the directory for attachment stats */ + attach_stats_kset = kset_create_and_add("attachments", NULL, + &sysfs_entry->kobj); + if (!attach_stats_kset) { + ret = -ENOMEM; + goto err_sysfs_attach; + } + + sysfs_entry->attach_stats_kset = attach_stats_kset; + + return 0; + +err_sysfs_attach: + kobject_del(&sysfs_entry->kobj); +err_sysfs_dmabuf: + kobject_put(&sysfs_entry->kobj); + dmabuf->sysfs_entry = NULL; + return ret; +} diff --git a/drivers/dma-buf/dma-buf-sysfs-stats.h b/drivers/dma-buf/dma-buf-sysfs-stats.h new file mode 100644 index 000000000000..5f4703249117 --- /dev/null +++ b/drivers/dma-buf/dma-buf-sysfs-stats.h @@ -0,0 +1,62 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * DMA-BUF sysfs statistics. + * + * Copyright (C) 2021 Google LLC. + */ + +#ifndef _DMA_BUF_SYSFS_STATS_H +#define _DMA_BUF_SYSFS_STATS_H + +#ifdef CONFIG_DMABUF_SYSFS_STATS + +int dma_buf_init_sysfs_statistics(void); +void dma_buf_uninit_sysfs_statistics(void); + +int dma_buf_stats_setup(struct dma_buf *dmabuf); +int dma_buf_attach_stats_setup(struct dma_buf_attachment *attach, + unsigned int uid); +static inline void dma_buf_update_attachment_map_count(struct dma_buf_attachment *attach, + int delta) +{ + struct dma_buf_attach_sysfs_entry *entry = attach->sysfs_entry; + + entry->map_counter += delta; +} +void dma_buf_stats_teardown(struct dma_buf *dmabuf); +void dma_buf_attach_stats_teardown(struct dma_buf_attachment *attach); +static inline unsigned int dma_buf_update_attach_uid(struct dma_buf *dmabuf) +{ + struct dma_buf_sysfs_entry *entry = dmabuf->sysfs_entry; + + return entry->attachment_uid++; +} +#else + +static inline int dma_buf_init_sysfs_statistics(void) +{ + return 0; +} + +static inline void dma_buf_uninit_sysfs_statistics(void) {} + +static inline int dma_buf_stats_setup(struct dma_buf *dmabuf) +{ + return 0; +} +static inline int dma_buf_attach_stats_setup(struct dma_buf_attachment *attach, + unsigned int uid) +{ + return 0; +} + +static inline void dma_buf_stats_teardown(struct dma_buf *dmabuf) {} +static inline void dma_buf_attach_stats_teardown(struct dma_buf_attachment *attach) {} +static inline void dma_buf_update_attachment_map_count(struct dma_buf_attachment *attach, + int delta) {} +static inline unsigned int dma_buf_update_attach_uid(struct dma_buf *dmabuf) +{ + return 0; +} +#endif +#endif // _DMA_BUF_SYSFS_STATS_H diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 9ad6397aaa97..29f9ea18eb47 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -29,6 +29,8 @@ #include <uapi/linux/dma-buf.h> #include <uapi/linux/magic.h> +#include "dma-buf-sysfs-stats.h" + static inline int is_dma_buf_file(struct file *); struct dma_buf_list { @@ -79,6 +81,7 @@ static void dma_buf_release(struct dentry *dentry) if (dmabuf->resv == (struct dma_resv *)&dmabuf[1]) dma_resv_fini(dmabuf->resv); + dma_buf_stats_teardown(dmabuf); module_put(dmabuf->owner); kfree(dmabuf->name); kfree(dmabuf); @@ -579,6 +582,10 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info) file->f_mode |= FMODE_LSEEK; dmabuf->file = file; + ret = dma_buf_stats_setup(dmabuf); + if (ret) + goto err_sysfs; + mutex_init(&dmabuf->lock); INIT_LIST_HEAD(&dmabuf->attachments); @@ -588,6 +595,14 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info) return dmabuf; +err_sysfs: + /* + * Set file->f_path.dentry->d_fsdata to NULL so that when + * dma_buf_release() gets invoked by dentry_ops, it exits + * early before calling the release() dma_buf op. + */ + file->f_path.dentry->d_fsdata = NULL; + fput(file); err_dmabuf: kfree(dmabuf); err_module: @@ -692,6 +707,7 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev, { struct dma_buf_attachment *attach; int ret; + unsigned int attach_uid; if (WARN_ON(!dmabuf || !dev)) return ERR_PTR(-EINVAL); @@ -717,8 +733,13 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev, } dma_resv_lock(dmabuf->resv, NULL); list_add(&attach->node, &dmabuf->attachments); + attach_uid = dma_buf_update_attach_uid(dmabuf); dma_resv_unlock(dmabuf->resv); + ret = dma_buf_attach_stats_setup(attach, attach_uid); + if (ret) + goto err_sysfs; + /* When either the importer or the exporter can't handle dynamic * mappings we cache the mapping here to avoid issues with the * reservation object lock. @@ -745,6 +766,7 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev, dma_resv_unlock(attach->dmabuf->resv); attach->sgt = sgt; attach->dir = DMA_BIDIRECTIONAL; + dma_buf_update_attachment_map_count(attach, 1 /* delta */); } return attach; @@ -761,6 +783,7 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev, if (dma_buf_is_dynamic(attach->dmabuf)) dma_resv_unlock(attach->dmabuf->resv); +err_sysfs: dma_buf_detach(dmabuf, attach); return ERR_PTR(ret); } @@ -799,6 +822,7 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach) dma_resv_lock(attach->dmabuf->resv, NULL); dmabuf->ops->unmap_dma_buf(attach, attach->sgt, attach->dir); + dma_buf_update_attachment_map_count(attach, -1 /* delta */); if (dma_buf_is_dynamic(attach->dmabuf)) { dma_buf_unpin(attach); @@ -812,6 +836,7 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach) if (dmabuf->ops->detach) dmabuf->ops->detach(dmabuf, attach); + dma_buf_attach_stats_teardown(attach); kfree(attach); } EXPORT_SYMBOL_GPL(dma_buf_detach); @@ -938,6 +963,9 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach, } #endif /* CONFIG_DMA_API_DEBUG */ + if (!IS_ERR(sg_table)) + dma_buf_update_attachment_map_count(attach, 1 /* delta */); + return sg_table; } EXPORT_SYMBOL_GPL(dma_buf_map_attachment); @@ -975,6 +1003,8 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment *attach, if (dma_buf_is_dynamic(attach->dmabuf) && !IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY)) dma_buf_unpin(attach); + + dma_buf_update_attachment_map_count(attach, -1 /* delta */); } EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment); @@ -1412,6 +1442,12 @@ static inline void dma_buf_uninit_debugfs(void) static int __init dma_buf_init(void) { + int ret; + + ret = dma_buf_init_sysfs_statistics(); + if (ret) + return ret; + dma_buf_mnt = kern_mount(&dma_buf_fs_type); if (IS_ERR(dma_buf_mnt)) return PTR_ERR(dma_buf_mnt); @@ -1427,5 +1463,6 @@ static void __exit dma_buf_deinit(void) { dma_buf_uninit_debugfs(); kern_unmount(dma_buf_mnt); + dma_buf_uninit_sysfs_statistics(); } __exitcall(dma_buf_deinit); diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index cf72699cb2bc..4ae5cc38a4a7 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -294,6 +294,9 @@ struct dma_buf_ops { * @poll: for userspace poll support * @cb_excl: for userspace poll support * @cb_shared: for userspace poll support + * @sysfs_entry: for exposing information about this buffer in sysfs. + * The attachment_uid member of @sysfs_entry is protected by dma_resv lock + * and is incremented on each attach. * * This represents a shared buffer, created by calling dma_buf_export(). The * userspace representation is a normal file descriptor, which can be created by @@ -329,6 +332,15 @@ struct dma_buf { __poll_t active; } cb_excl, cb_shared; +#ifdef CONFIG_DMABUF_SYSFS_STATS + /* for sysfs stats */ + struct dma_buf_sysfs_entry { + struct kobject kobj; + struct dma_buf *dmabuf; + unsigned int attachment_uid; + struct kset *attach_stats_kset; + } *sysfs_entry; +#endif }; /** @@ -378,6 +390,7 @@ struct dma_buf_attach_ops { * @importer_ops: importer operations for this attachment, if provided * dma_buf_map/unmap_attachment() must be called with the dma_resv lock held. * @importer_priv: importer specific attachment data. + * @sysfs_entry: For exposing information about this attachment in sysfs. * * This structure holds the attachment information between the dma_buf buffer * and its user device(s). The list contains one attachment struct per device @@ -398,6 +411,13 @@ struct dma_buf_attachment { const struct dma_buf_attach_ops *importer_ops; void *importer_priv; void *priv; +#ifdef CONFIG_DMABUF_SYSFS_STATS + /* for sysfs stats */ + struct dma_buf_attach_sysfs_entry { + struct kobject kobj; + unsigned int map_counter; + } *sysfs_entry; +#endif }; /**
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/<inode_number>/exporter_name /sys/kernel/dmabuf/buffers/<inode_number>/size /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attach_uid>/device /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attach_uid>/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 <hridya@google.com> Reported-by: kernel test robot <lkp@intel.com> --- 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