From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: "Christian König" <christian.koenig@amd.com>,
"Rob Clark" <robdclark@gmail.com>,
dri-devel@lists.freedesktop.org
Cc: "open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
"open list" <linux-kernel@vger.kernel.org>,
"Michel Dänzer" <mdaenzer@redhat.com>,
"YiPeng Chai" <YiPeng.Chai@amd.com>,
"Mario Limonciello" <mario.limonciello@amd.com>,
"Rob Clark" <robdclark@chromium.org>,
"Guchun Chen" <guchun.chen@amd.com>,
"Shashank Sharma" <shashank.sharma@amd.com>,
"open list:RADEON and AMDGPU DRM DRIVERS"
<amd-gfx@lists.freedesktop.org>,
"Russell King" <linux+etnaviv@armlinux.org.uk>,
"Arunpravin Paneer Selvam" <Arunpravin.PaneerSelvam@amd.com>,
linux-arm-msm@vger.kernel.org, intel-gfx@lists.freedesktop.org,
"moderated list:DRM DRIVERS FOR VIVANTE GPU IP"
<etnaviv@lists.freedesktop.org>,
"Christian Gmeiner" <christian.gmeiner@gmail.com>,
"Evan Quan" <evan.quan@amd.com>, "Sean Paul" <sean@poorly.run>,
"Tvrtko Ursulin" <tvrtko.ursulin@intel.com>,
"Emil Velikov" <emil.l.velikov@gmail.com>,
"Christopher Healy" <healych@amazon.com>,
"Boris Brezillon" <boris.brezillon@collabora.com>,
"Alex Deucher" <alexander.deucher@amd.com>,
freedreno@lists.freedesktop.org,
"Hawking Zhang" <Hawking.Zhang@amd.com>
Subject: Re: [PATCH v3 0/7] drm: fdinfo memory stats
Date: Wed, 12 Apr 2023 13:10:22 +0100 [thread overview]
Message-ID: <98bb3388-d671-dcf3-0247-649a702b5e11@linux.intel.com> (raw)
In-Reply-To: <bbbbbf34-2ea5-5344-30db-f976c5198d75@amd.com>
On 12/04/2023 10:34, Christian König wrote:
> Am 12.04.23 um 00:56 schrieb Rob Clark:
>> From: Rob Clark <robdclark@chromium.org>
>>
>> Similar motivation to other similar recent attempt[1]. But with an
>> attempt to have some shared code for this. As well as documentation.
>>
>> It is probably a bit UMA-centric, I guess devices with VRAM might want
>> some placement stats as well. But this seems like a reasonable start.
>>
>> Basic gputop support: https://patchwork.freedesktop.org/series/116236/
>> And already nvtop support: https://github.com/Syllo/nvtop/pull/204
>>
>> [1] https://patchwork.freedesktop.org/series/112397/
>
> I think the extra client id looks a bit superfluous since the ino of the
> file should already be unique and IIRC we have been already using that one.
Do you mean file_inode(struct drm_file->filp)->i_ino ? That one would be
the same number for all clients which open the same device node so
wouldn't work.
I also don't think the atomic_add_return for client id works either,
since it can alias on overflow.
In i915 I use an xarray and __xa_alloc_cyclic.
Regards,
Tvrtko
WARNING: multiple messages have this Message-ID (diff)
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: "Christian König" <christian.koenig@amd.com>,
"Rob Clark" <robdclark@gmail.com>,
dri-devel@lists.freedesktop.org
Cc: "open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
"open list" <linux-kernel@vger.kernel.org>,
"Michel Dänzer" <mdaenzer@redhat.com>,
"YiPeng Chai" <YiPeng.Chai@amd.com>,
"Mario Limonciello" <mario.limonciello@amd.com>,
"Rob Clark" <robdclark@chromium.org>,
"Guchun Chen" <guchun.chen@amd.com>,
"open list:RADEON and AMDGPU DRM DRIVERS"
<amd-gfx@lists.freedesktop.org>,
"Russell King" <linux+etnaviv@armlinux.org.uk>,
"Arunpravin Paneer Selvam" <Arunpravin.PaneerSelvam@amd.com>,
linux-arm-msm@vger.kernel.org, intel-gfx@lists.freedesktop.org,
"moderated list:DRM DRIVERS FOR VIVANTE GPU IP"
<etnaviv@lists.freedesktop.org>,
"Christian Gmeiner" <christian.gmeiner@gmail.com>,
"Evan Quan" <evan.quan@amd.com>,
"Christopher Healy" <healych@amazon.com>,
"Alex Deucher" <alexander.deucher@amd.com>,
freedreno@lists.freedesktop.org,
"Hawking Zhang" <Hawking.Zhang@amd.com>
Subject: Re: [Intel-gfx] [PATCH v3 0/7] drm: fdinfo memory stats
Date: Wed, 12 Apr 2023 13:10:22 +0100 [thread overview]
Message-ID: <98bb3388-d671-dcf3-0247-649a702b5e11@linux.intel.com> (raw)
In-Reply-To: <bbbbbf34-2ea5-5344-30db-f976c5198d75@amd.com>
On 12/04/2023 10:34, Christian König wrote:
> Am 12.04.23 um 00:56 schrieb Rob Clark:
>> From: Rob Clark <robdclark@chromium.org>
>>
>> Similar motivation to other similar recent attempt[1]. But with an
>> attempt to have some shared code for this. As well as documentation.
>>
>> It is probably a bit UMA-centric, I guess devices with VRAM might want
>> some placement stats as well. But this seems like a reasonable start.
>>
>> Basic gputop support: https://patchwork.freedesktop.org/series/116236/
>> And already nvtop support: https://github.com/Syllo/nvtop/pull/204
>>
>> [1] https://patchwork.freedesktop.org/series/112397/
>
> I think the extra client id looks a bit superfluous since the ino of the
> file should already be unique and IIRC we have been already using that one.
Do you mean file_inode(struct drm_file->filp)->i_ino ? That one would be
the same number for all clients which open the same device node so
wouldn't work.
I also don't think the atomic_add_return for client id works either,
since it can alias on overflow.
In i915 I use an xarray and __xa_alloc_cyclic.
Regards,
Tvrtko
WARNING: multiple messages have this Message-ID (diff)
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: "Christian König" <christian.koenig@amd.com>,
"Rob Clark" <robdclark@gmail.com>,
dri-devel@lists.freedesktop.org
Cc: linux-arm-msm@vger.kernel.org, freedreno@lists.freedesktop.org,
"Boris Brezillon" <boris.brezillon@collabora.com>,
"Christopher Healy" <healych@amazon.com>,
"Emil Velikov" <emil.l.velikov@gmail.com>,
"Rob Clark" <robdclark@chromium.org>,
"Alex Deucher" <alexander.deucher@amd.com>,
"open list:RADEON and AMDGPU DRM DRIVERS"
<amd-gfx@lists.freedesktop.org>,
"Arunpravin Paneer Selvam" <Arunpravin.PaneerSelvam@amd.com>,
"Christian Gmeiner" <christian.gmeiner@gmail.com>,
"moderated list:DRM DRIVERS FOR VIVANTE GPU IP"
<etnaviv@lists.freedesktop.org>, "Evan Quan" <evan.quan@amd.com>,
"Guchun Chen" <guchun.chen@amd.com>,
"Hawking Zhang" <Hawking.Zhang@amd.com>,
intel-gfx@lists.freedesktop.org,
"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
"open list" <linux-kernel@vger.kernel.org>,
"Mario Limonciello" <mario.limonciello@amd.com>,
"Michel Dänzer" <mdaenzer@redhat.com>,
"Russell King" <linux+etnaviv@armlinux.org.uk>,
"Sean Paul" <sean@poorly.run>,
"Shashank Sharma" <shashank.sharma@amd.com>,
"Tvrtko Ursulin" <tvrtko.ursulin@intel.com>,
"YiPeng Chai" <YiPeng.Chai@amd.com>
Subject: Re: [PATCH v3 0/7] drm: fdinfo memory stats
Date: Wed, 12 Apr 2023 13:10:22 +0100 [thread overview]
Message-ID: <98bb3388-d671-dcf3-0247-649a702b5e11@linux.intel.com> (raw)
In-Reply-To: <bbbbbf34-2ea5-5344-30db-f976c5198d75@amd.com>
On 12/04/2023 10:34, Christian König wrote:
> Am 12.04.23 um 00:56 schrieb Rob Clark:
>> From: Rob Clark <robdclark@chromium.org>
>>
>> Similar motivation to other similar recent attempt[1]. But with an
>> attempt to have some shared code for this. As well as documentation.
>>
>> It is probably a bit UMA-centric, I guess devices with VRAM might want
>> some placement stats as well. But this seems like a reasonable start.
>>
>> Basic gputop support: https://patchwork.freedesktop.org/series/116236/
>> And already nvtop support: https://github.com/Syllo/nvtop/pull/204
>>
>> [1] https://patchwork.freedesktop.org/series/112397/
>
> I think the extra client id looks a bit superfluous since the ino of the
> file should already be unique and IIRC we have been already using that one.
Do you mean file_inode(struct drm_file->filp)->i_ino ? That one would be
the same number for all clients which open the same device node so
wouldn't work.
I also don't think the atomic_add_return for client id works either,
since it can alias on overflow.
In i915 I use an xarray and __xa_alloc_cyclic.
Regards,
Tvrtko
WARNING: multiple messages have this Message-ID (diff)
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: "Christian König" <christian.koenig@amd.com>,
"Rob Clark" <robdclark@gmail.com>,
dri-devel@lists.freedesktop.org
Cc: "open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
"open list" <linux-kernel@vger.kernel.org>,
"Michel Dänzer" <mdaenzer@redhat.com>,
"YiPeng Chai" <YiPeng.Chai@amd.com>,
"Mario Limonciello" <mario.limonciello@amd.com>,
"Rob Clark" <robdclark@chromium.org>,
"Guchun Chen" <guchun.chen@amd.com>,
"Shashank Sharma" <shashank.sharma@amd.com>,
"open list:RADEON and AMDGPU DRM DRIVERS"
<amd-gfx@lists.freedesktop.org>,
"Russell King" <linux+etnaviv@armlinux.org.uk>,
"Arunpravin Paneer Selvam" <Arunpravin.PaneerSelvam@amd.com>,
linux-arm-msm@vger.kernel.org, intel-gfx@lists.freedesktop.org,
"moderated list:DRM DRIVERS FOR VIVANTE GPU IP"
<etnaviv@lists.freedesktop.org>, "Evan Quan" <evan.quan@amd.com>,
"Sean Paul" <sean@poorly.run>,
"Tvrtko Ursulin" <tvrtko.ursulin@intel.com>,
"Emil Velikov" <emil.l.velikov@gmail.com>,
"Christopher Healy" <healych@amazon.com>,
"Boris Brezillon" <boris.brezillon@collabora.com>,
"Alex Deucher" <alexander.deucher@amd.com>,
freedreno@lists.freedesktop.org,
"Hawking Zhang" <Hawking.Zhang@amd.com>
Subject: Re: [PATCH v3 0/7] drm: fdinfo memory stats
Date: Wed, 12 Apr 2023 13:10:22 +0100 [thread overview]
Message-ID: <98bb3388-d671-dcf3-0247-649a702b5e11@linux.intel.com> (raw)
In-Reply-To: <bbbbbf34-2ea5-5344-30db-f976c5198d75@amd.com>
On 12/04/2023 10:34, Christian König wrote:
> Am 12.04.23 um 00:56 schrieb Rob Clark:
>> From: Rob Clark <robdclark@chromium.org>
>>
>> Similar motivation to other similar recent attempt[1]. But with an
>> attempt to have some shared code for this. As well as documentation.
>>
>> It is probably a bit UMA-centric, I guess devices with VRAM might want
>> some placement stats as well. But this seems like a reasonable start.
>>
>> Basic gputop support: https://patchwork.freedesktop.org/series/116236/
>> And already nvtop support: https://github.com/Syllo/nvtop/pull/204
>>
>> [1] https://patchwork.freedesktop.org/series/112397/
>
> I think the extra client id looks a bit superfluous since the ino of the
> file should already be unique and IIRC we have been already using that one.
Do you mean file_inode(struct drm_file->filp)->i_ino ? That one would be
the same number for all clients which open the same device node so
wouldn't work.
I also don't think the atomic_add_return for client id works either,
since it can alias on overflow.
In i915 I use an xarray and __xa_alloc_cyclic.
Regards,
Tvrtko
next prev parent reply other threads:[~2023-04-12 12:11 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-11 22:56 [PATCH v3 0/7] drm: fdinfo memory stats Rob Clark
2023-04-11 22:56 ` Rob Clark
2023-04-11 22:56 ` Rob Clark
2023-04-11 22:56 ` [Intel-gfx] " Rob Clark
2023-04-11 22:56 ` [PATCH v3 1/7] drm: Add common fdinfo helper Rob Clark
2023-04-11 22:56 ` Rob Clark
2023-04-12 7:55 ` Daniel Vetter
2023-04-12 7:55 ` Daniel Vetter
2023-04-11 22:56 ` [PATCH v3 2/7] drm/msm: Switch to " Rob Clark
2023-04-11 22:56 ` Rob Clark
2023-04-11 22:56 ` [PATCH v3 3/7] drm/amdgpu: " Rob Clark
2023-04-11 22:56 ` Rob Clark
2023-04-11 22:56 ` Rob Clark
2023-04-12 7:58 ` Daniel Vetter
2023-04-12 7:58 ` Daniel Vetter
2023-04-12 7:58 ` Daniel Vetter
2023-04-11 22:56 ` [Intel-gfx] [PATCH v3 4/7] drm/i915: " Rob Clark
2023-04-11 22:56 ` Rob Clark
2023-04-11 22:56 ` Rob Clark
2023-04-12 12:32 ` [Intel-gfx] " Tvrtko Ursulin
2023-04-12 12:32 ` Tvrtko Ursulin
2023-04-12 12:32 ` Tvrtko Ursulin
2023-04-12 13:51 ` [Intel-gfx] " Daniel Vetter
2023-04-12 13:51 ` Daniel Vetter
2023-04-12 13:51 ` Daniel Vetter
2023-04-12 15:12 ` [Intel-gfx] " Tvrtko Ursulin
2023-04-12 15:12 ` Tvrtko Ursulin
2023-04-12 18:13 ` [Intel-gfx] " Daniel Vetter
2023-04-12 18:13 ` Daniel Vetter
2023-04-12 18:13 ` Daniel Vetter
2023-04-11 22:56 ` [PATCH v3 5/7] drm/etnaviv: " Rob Clark
2023-04-11 22:56 ` Rob Clark
2023-04-12 7:59 ` Daniel Vetter
2023-04-12 7:59 ` Daniel Vetter
2023-04-12 22:18 ` Rob Clark
2023-04-12 22:18 ` Rob Clark
2023-04-11 22:56 ` [PATCH v3 6/7] drm: Add fdinfo memory stats Rob Clark
2023-04-11 22:56 ` Rob Clark
2023-04-12 8:01 ` Daniel Vetter
2023-04-12 8:01 ` Daniel Vetter
2023-04-12 14:42 ` Tvrtko Ursulin
2023-04-12 14:42 ` Tvrtko Ursulin
2023-04-12 17:59 ` Rob Clark
2023-04-12 17:59 ` Rob Clark
2023-04-12 18:17 ` Daniel Vetter
2023-04-12 18:17 ` Daniel Vetter
2023-04-12 18:42 ` Rob Clark
2023-04-12 18:42 ` Rob Clark
2023-04-12 19:18 ` Daniel Vetter
2023-04-12 19:18 ` Daniel Vetter
2023-04-13 12:58 ` Tvrtko Ursulin
2023-04-13 13:27 ` Daniel Vetter
2023-04-13 13:27 ` Daniel Vetter
2023-04-13 16:40 ` Tvrtko Ursulin
2023-04-13 18:24 ` Rob Clark
2023-04-13 18:24 ` Rob Clark
2023-04-13 20:05 ` Daniel Vetter
2023-04-13 20:05 ` Daniel Vetter
2023-04-14 8:57 ` Tvrtko Ursulin
2023-04-14 9:07 ` Daniel Vetter
2023-04-14 9:07 ` Daniel Vetter
2023-04-14 10:12 ` Tvrtko Ursulin
2023-04-14 10:12 ` Tvrtko Ursulin
2023-04-14 13:40 ` Rob Clark
2023-04-14 13:40 ` Rob Clark
2023-04-16 7:48 ` Daniel Vetter
2023-04-16 7:48 ` Daniel Vetter
2023-04-17 11:10 ` Tvrtko Ursulin
2023-04-17 13:42 ` Rob Clark
2023-04-17 13:42 ` Rob Clark
2023-04-17 14:04 ` Alex Deucher
2023-04-17 14:04 ` Alex Deucher
2023-04-17 14:20 ` Tvrtko Ursulin
2023-04-17 14:20 ` Tvrtko Ursulin
2023-04-17 16:12 ` Rob Clark
2023-04-17 16:12 ` Rob Clark
2023-04-13 15:47 ` Rob Clark
2023-04-13 15:47 ` Rob Clark
2023-04-13 16:45 ` Alex Deucher
2023-04-13 16:45 ` Alex Deucher
2023-04-11 22:56 ` [PATCH v3 7/7] drm/msm: Add memory stats to fdinfo Rob Clark
2023-04-11 22:56 ` Rob Clark
2023-04-12 9:34 ` [PATCH v3 0/7] drm: fdinfo memory stats Christian König
2023-04-12 9:34 ` Christian König
2023-04-12 9:34 ` Christian König
2023-04-12 9:34 ` [Intel-gfx] " Christian König
2023-04-12 12:10 ` Tvrtko Ursulin [this message]
2023-04-12 12:10 ` Tvrtko Ursulin
2023-04-12 12:10 ` Tvrtko Ursulin
2023-04-12 12:10 ` [Intel-gfx] " Tvrtko Ursulin
2023-04-12 12:22 ` Christian König
2023-04-12 12:22 ` Christian König
2023-04-12 12:22 ` Christian König
2023-04-12 12:22 ` [Intel-gfx] " Christian König
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=98bb3388-d671-dcf3-0247-649a702b5e11@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=Arunpravin.PaneerSelvam@amd.com \
--cc=Hawking.Zhang@amd.com \
--cc=YiPeng.Chai@amd.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=boris.brezillon@collabora.com \
--cc=christian.gmeiner@gmail.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=emil.l.velikov@gmail.com \
--cc=etnaviv@lists.freedesktop.org \
--cc=evan.quan@amd.com \
--cc=freedreno@lists.freedesktop.org \
--cc=guchun.chen@amd.com \
--cc=healych@amazon.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux+etnaviv@armlinux.org.uk \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=mdaenzer@redhat.com \
--cc=robdclark@chromium.org \
--cc=robdclark@gmail.com \
--cc=sean@poorly.run \
--cc=shashank.sharma@amd.com \
--cc=tvrtko.ursulin@intel.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.