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: 1332 bytes --]

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

>> 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.
>
> Perhaps, but really, the only thing you would probably save by using
> spinlocks in the fast path is retrying in nouveau_sem_alloc, which
> should be at most 10 lines saved.
>
You'd also save some bookkeeping and the double error checking.

> You could save much more by supporting only a single static semaphore
> BO, and still retain almost all flexibility by making it large.
> However, it's somewhat inelegant, and why not just keep the
> functionality so we never need to revisit this again?

Yup, I'm fine with having several semaphore BOs.

>
>> BTW, the kernel has some linked list helpers you might want to use for
>> sem_bo_free_list
> It is a singly linked list, and slist.h never got merged.
> I could possibly make it doubly linked, even though it's a bit useless.
>
>> and probably the best place for the sem stuff to live
>> is "dev_priv->fence" instead of the root of drm_nouveau_private.
> There is no "fence" currently in drm_nouveau_private.
> Adding a "sem" or "fence" substructure could make sense though.

Yes, that would make sense.

[-- 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