From: Philipp Stanner <phasta@mailbox.org>
To: "Christian König" <christian.koenig@amd.com>,
"Danilo Krummrich" <dakr@kernel.org>
Cc: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>,
alexander.deucher@amd.com, amd-gfx@lists.freedesktop.org,
Philipp Stanner <phasta@kernel.org>,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v1] drm/amdgpu: give each kernel job a unique id
Date: Fri, 13 Jun 2025 10:29:35 +0200 [thread overview]
Message-ID: <a495f31526f19457f44d502cf2de98ab0de33383.camel@mailbox.org> (raw)
In-Reply-To: <099816b4-0b7b-4ac7-9bb5-22f23b1db7b7@amd.com>
On Fri, 2025-06-13 at 10:23 +0200, Christian König wrote:
> On 6/13/25 01:48, Danilo Krummrich wrote:
> > On Thu, Jun 12, 2025 at 09:00:34AM +0200, Christian König wrote:
> > > On 6/11/25 17:11, Danilo Krummrich wrote:
> > > > > > > Mhm, reiterating our internal discussion on the mailing
> > > > > > > list.
> > > > > > >
> > > > > > > I think it would be nicer if we could use negative values
> > > > > > > for the kernel submissions and positive for userspace.
> > > > > > > But as discussed internally we would need to adjust the
> > > > > > > scheduler trace points for that once more.
> > > > > > >
> > > > > > > @Philip and @Danilo any opinion on that?
> > > > > >
> > > > > > Both, the U64_MAX and the positive-negative approach, are a
> > > > > > bit hacky. I wonder
> > > > > > why we need client_id to be a u64, wouldn't a u32 not be
> > > > > > enough?
> > > > >
> > > > > That can trivially overflow on long running boxes.
> > > >
> > > > I don't know if "trivially" is the word of choice given that
> > > > the number is
> > > > 4,294,967,295.
> > > >
> > > > But I did indeed miss that this is a for ever increasing
> > > > atomic. Why is it an
> > > > atomic? Why is it not an IDA?
> > >
> > > Well IDA has some extra overhead compared to an ever increasing
> > > atomic, additional to that it might not be the best choice to re-
> > > use numbers for clients in a trace log.
> >
> > I think the overhead is not relevant at all, this is called from
> > drm_file_alloc(). The only path I can see where this is called is
> > drm_client_init(), which isn't high frequent stuff at all, is it?
>
> I don't think so. But we should really use ida_alloc_cyclic to make
> sure that numbers are not re-used so quickly.
Shouldn't the xarray be used nowadays for ID allocation? I think
idr_alloc_cyclic() (ida_alloc_cyclic() doesn't exist) is just a wrapper
around the xarray anyways.
P.
>
> >
> > It seems to me that we should probably use IDA here.
> >
> > > On the other hand using smaller numbers is usually nicer for
> > > manual inspection.
> >
> > Another option is to just add an interface to get a kernel
> > client_id from the
> > same atomic / IDA.
>
> That won't give us fixed numbers for in kernel clients.
>
> Regards,
> Christian.
next prev parent reply other threads:[~2025-06-13 16:06 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-04 12:28 [PATCH v1] drm/amdgpu: give each kernel job a unique id Pierre-Eric Pelloux-Prayer
2025-06-10 13:05 ` Christian König
2025-06-11 14:25 ` Danilo Krummrich
2025-06-11 14:57 ` Christian König
2025-06-11 15:11 ` Danilo Krummrich
2025-06-12 7:00 ` Christian König
2025-06-12 23:48 ` Danilo Krummrich
2025-06-13 7:51 ` Pierre-Eric Pelloux-Prayer
2025-06-13 8:31 ` Danilo Krummrich
2025-06-13 8:23 ` Christian König
2025-06-13 8:29 ` Philipp Stanner [this message]
2025-06-13 8:42 ` Danilo Krummrich
2025-06-13 8:35 ` Danilo Krummrich
2025-06-13 9:27 ` Pierre-Eric Pelloux-Prayer
2025-06-13 11:48 ` Danilo Krummrich
2025-06-18 9:18 ` Pierre-Eric Pelloux-Prayer
2025-07-02 9:23 ` Pierre-Eric Pelloux-Prayer
2025-07-02 9:42 ` Danilo Krummrich
2025-08-01 15:34 ` Alex Deucher
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=a495f31526f19457f44d502cf2de98ab0de33383.camel@mailbox.org \
--to=phasta@mailbox.org \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=phasta@kernel.org \
--cc=pierre-eric.pelloux-prayer@amd.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).