From: Charan Teja Kalla <quic_charante@quicinc.com>
To: "Christian König" <christian.koenig@amd.com>,
gregkh@linuxfoundation.org, sumit.semwal@linaro.org,
hridya@google.com, daniel.vetter@ffwll.ch, tjmercier@google.com
Cc: linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org
Subject: Re: [PATCH V2] dmabuf: ensure unique directory name for dmabuf stats
Date: Thu, 12 May 2022 20:20:07 +0530 [thread overview]
Message-ID: <9be4ea50-4dc0-50f0-0552-e4b9e4feafa2@quicinc.com> (raw)
In-Reply-To: <93103bb7-8d67-a9ae-31c8-d53cb651a027@amd.com>
Thanks Christian for the comments!!
On 5/11/2022 12:33 PM, Christian König wrote:
>
>> The single number approach, generated by atomic, wouldn't break the
>> uapi, but that number won't give any meaningful information especially
>> when this is targeted just for debug purpose. And just 'inode' is not
>> usable for already stated reasons.
>
> Well, why do you want to use the ino in the first place? This is an
> anonymous inode not associated with any filesystem, so that number is
> meaningless anyway.
>
It is just for ease of debugging. Nothing more. I can quickly traverse
the /sys/kernel/dmabuf/buffers/* and get complete information about the
dmabuf buffers while relating to which process this buffer is allocated
by, using this inode as the 'unique' reference.
https://cs.android.com/android/platform/superproject/+/master:system/memory/libmeminfo/libdmabufinfo/tools/dmabuf_dump.cpp
>> How about using the atomic number generated it self used as inode
>> number? I see tmpfs also maintains its own inode numbers for the same
>> overflow reasons[2].
>
> Yeah, that could potentially work as well.
>
Thanks. Will work on the next version of this patch.
> Regards,
> Christian.
WARNING: multiple messages have this Message-ID (diff)
From: Charan Teja Kalla <quic_charante@quicinc.com>
To: "Christian König" <christian.koenig@amd.com>,
gregkh@linuxfoundation.org, sumit.semwal@linaro.org,
hridya@google.com, daniel.vetter@ffwll.ch, tjmercier@google.com
Cc: <linux-kernel@vger.kernel.org>, <linux-media@vger.kernel.org>,
<dri-devel@lists.freedesktop.org>,
<linaro-mm-sig@lists.linaro.org>
Subject: Re: [PATCH V2] dmabuf: ensure unique directory name for dmabuf stats
Date: Thu, 12 May 2022 20:20:07 +0530 [thread overview]
Message-ID: <9be4ea50-4dc0-50f0-0552-e4b9e4feafa2@quicinc.com> (raw)
In-Reply-To: <93103bb7-8d67-a9ae-31c8-d53cb651a027@amd.com>
Thanks Christian for the comments!!
On 5/11/2022 12:33 PM, Christian König wrote:
>
>> The single number approach, generated by atomic, wouldn't break the
>> uapi, but that number won't give any meaningful information especially
>> when this is targeted just for debug purpose. And just 'inode' is not
>> usable for already stated reasons.
>
> Well, why do you want to use the ino in the first place? This is an
> anonymous inode not associated with any filesystem, so that number is
> meaningless anyway.
>
It is just for ease of debugging. Nothing more. I can quickly traverse
the /sys/kernel/dmabuf/buffers/* and get complete information about the
dmabuf buffers while relating to which process this buffer is allocated
by, using this inode as the 'unique' reference.
https://cs.android.com/android/platform/superproject/+/master:system/memory/libmeminfo/libdmabufinfo/tools/dmabuf_dump.cpp
>> How about using the atomic number generated it self used as inode
>> number? I see tmpfs also maintains its own inode numbers for the same
>> overflow reasons[2].
>
> Yeah, that could potentially work as well.
>
Thanks. Will work on the next version of this patch.
> Regards,
> Christian.
next prev parent reply other threads:[~2022-05-12 14:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-10 14:06 [PATCH V2] dmabuf: ensure unique directory name for dmabuf stats Charan Teja Kalla
2022-05-10 14:06 ` Charan Teja Kalla
2022-05-10 15:12 ` Christian König
2022-05-10 15:12 ` Christian König
2022-05-10 17:14 ` Charan Teja Kalla
2022-05-10 17:14 ` Charan Teja Kalla
2022-05-10 17:22 ` Christian König
2022-05-10 17:22 ` Christian König
2022-05-11 6:49 ` Charan Teja Kalla
2022-05-11 6:49 ` Charan Teja Kalla
2022-05-11 7:03 ` Christian König
2022-05-11 7:03 ` Christian König
2022-05-12 14:50 ` Charan Teja Kalla [this message]
2022-05-12 14:50 ` Charan Teja Kalla
2022-05-10 17:11 ` T.J. Mercier
2022-05-10 17:11 ` T.J. Mercier
2022-05-10 21:55 ` kernel test robot
2022-05-10 21:55 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9be4ea50-4dc0-50f0-0552-e4b9e4feafa2@quicinc.com \
--to=quic_charante@quicinc.com \
--cc=christian.koenig@amd.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=hridya@google.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=sumit.semwal@linaro.org \
--cc=tjmercier@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.