Re: [PATCH 2/3] drm/nouveau: add lockless dynamic semaphore allocator

[Francisco Jerez <currojerez-sGOZH3hwPm2sTnJN9+BGXg@public.gmane.org>]

[-- Attachment #1.1.1: Type: text/plain, Size: 1437 bytes --]

Luca Barbieri <luca-Ukmtq+NC3rhBHFWNQifrYwC/G2K4zDHf@public.gmane.org> writes:

>> How often do we expect cross-channel sync to kick in? Maybe 2-3 times
>> per frame? I suspect contentions will be rare enough to make spinlocks
>> as fast as atomics for all real-life cases, and they don't have such a
>> high maintainability cost. What do you guys think?
>
> For the case of a single (or a few) GL application the requirements
> are indeed modest.
>
> I'm not sure that spinlocks or an otherwise reduced solution would be
> much simpler.
> You basically would just avoid the retrying code.
>
> Also if you have a multithreaded/multiprocess GPGPU application on
> large SMP machine things may change, as you may have a lot of commands
> and semaphores in flight, as well as high contention for anything
> global.
>
Sounds like premature optimization to me. I'm just stating my personal
view here, but I have a feeling a patch with 60% of lines could do very
well the same for most realistic cases.

Maarten, Ben, what do you think about this?

> Of course, currently we hold both the BKL and struct_mutex around
> things, which makes it all moot, but hopefully we'll switch to
> per-channel mutexes soon (I'm looking into that).

BTW, the kernel has some linked list helpers you might want to use for
sem_bo_free_list, and probably the best place for the sem stuff to live
is "dev_priv->fence" instead of the root of drm_nouveau_private.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 181 bytes --]

_______________________________________________
Nouveau mailing list
Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
http://lists.freedesktop.org/mailman/listinfo/nouveau