[PATCH 1/4] drm/sched: optimize drm_sched_job_add_dependency

[Christian König]

On 5/26/25 13:14, Danilo Krummrich wrote:
> (Cc: Matthew)
> 
> Let's get this clarified to not work with assumptions. :)
> 
> On Mon, May 26, 2025 at 12:59:41PM +0200, Christian König wrote:
>> On 5/24/25 13:17, Danilo Krummrich wrote:
>>> On Fri, May 23, 2025 at 04:11:39PM +0200, Danilo Krummrich wrote:
>>> So, your code here should be correct. However, I'd still remove the goto and
>>> just call xas_store() again. There's no reason to make this a loop and backwards
>>> goto is better avoided anyways. :)
>>
>>
>> I was considering that as well, but than abandoned this idea. The xarray() sample code and test cases as well as the use cases where I took a look either use a loop or a goto.
>>
>> I'm not 100% sure why, my suspicion is that you need the loop when there can be concurrent add/remove operations on the xarray, but I think we should stick with the common approach.
> 
> I don't think that concurrency is relevant here. xas_nomem() stores the
> allocated memory in the XA_STATE structure, which is on the stack.

Yeah, but it could be that when you have a concurrent remove that this memory isn't sufficient and you need even more.

> I know that for maple tree a pre-allocation is only valid for the exact state
> of the tree it was allocated for.
> 
> But I think xarray does not have this limitation, i.e. concurrent modification
> of the xarray does not invalidate an xas_nomem() allocation in terms of being
> sufficient for a subsequent store.
> 
> @Matthew: Can you clarify this please?

While at it: Is it possible to run the xarray without locking?

We have exactly one thread handling the job at all times, so no concurrent accesses whatsoever.

Acquiring and dropping the lock is just additional overhead and without it the memory can also be allocated just with GFP_KERNEL.

Regards,
Christian.