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