amd-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
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.


  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).