> 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 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? > 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. _______________________________________________ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau