All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <ckoenig.leichtzumerken@gmail.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	linaro-mm-sig@lists.linaro.org, dri-devel@lists.freedesktop.org,
	linux-media@vger.kernel.org
Cc: daniel@ffwll.ch, intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 01/26] dma-buf: add dma_resv_for_each_fence_unlocked
Date: Wed, 15 Sep 2021 12:46:22 +0200	[thread overview]
Message-ID: <4da378ec-0411-aaf5-fb02-e3a18e7175d3@gmail.com> (raw)
In-Reply-To: <c03a61f2-9d70-c6f4-584d-b91c89ec7462@linux.intel.com>

Am 14.09.21 um 15:07 schrieb Tvrtko Ursulin:
> On 14/09/2021 12:25, Christian König wrote:
>> Am 14.09.21 um 12:53 schrieb Tvrtko Ursulin:
>>>
>>> On 13/09/2021 14:16, Christian König wrote:
>>>> [SNIP]
>>>> +        if (fence) {
>>>> +            fence = dma_fence_get_rcu(fence);
>>>> +        } else if (all_fences && cursor->fences) {
>>>> +            struct dma_resv_list *fences = cursor->fences;
>>>
>>> If rcu lock is allowed to be dropped while walking the list what 
>>> guarantees list of fences hasn't been freed?
>>
>> Ah, good point! We need to test the sequence number when we enter the 
>> function as well. Going to fix that.
>
> Right, but just to say, I am still on the fence a bit on the concept 
> of the unlocked iterator. So for now I am looking only superficially 
> at the implementation and i915 side of things.

I'm really in favor of taking the lock as well and contain the unlocked 
operation into the dma_resv object code and I think Daniel is on 
absolutely the same side as well.

But the use cases are as they are for now and I think containing the 
internal structure of the dma_resv object is the right next step.

>>> [SNIP]
>>>>   +/**
>>>> + * struct dma_resv_cursor - current position into the dma_resv fences
>>>> + * @seq: sequence number to check
>>>> + * @index: index into the shared fences
>>>> + * @shared: the shared fences
>>>> + * @is_first: true if this is the first returned fence
>>>> + * @is_exclusive: if the current fence is the exclusive one
>>>> + */
>>>> +struct dma_resv_cursor {
>>>> +    unsigned int seq;
>>>> +    unsigned int index;
>>>> +    struct dma_resv_list *fences;
>>>> +    bool is_first;
>>>
>>> Is_first is useful to callers - like they are legitimately allowed 
>>> to look inside this, what could otherwise be private object?
>>
>> Yes, I was pondering on the same question. Key point is that this is 
>> only used by other dma_resv functions which also use cursor.fences 
>> for example.
>>
>> So this is only supposed to be used by code working with other 
>> privates of the dma_resv object as well.
>
> Hmmm and you think external callers have no legitimate case of 
> detecting restarts?

Yes, if somebody needs a snapshot of the current state and can't for 
some reason take the lock they should use dma_resv_get_fences() instead.

On the other hand allocating memory in dma_resv_get_fences() has 
probably more overhead than just grabbing and releasing the lock.

> Or to better say will not have the need of distinguishing between real 
> restarts and just the first iteration? I need to read more of the 
> series to get a more complete opinion here.

Yeah, that's indeed a good point. Off hand I don't see any, but we 
should probably decide for each place individually if we should take the 
lock, allocate memory or use the lockless iterator.

> [SNIP]
>>>
>>>> +};
>>>> +
>>>> +/**
>>>> + * dma_resv_for_each_fence_unlocked - fence iterator
>>>> + * @obj: a dma_resv object pointer
>>>> + * @cursor: a struct dma_resv_cursor pointer
>>>> + * @all_fences: true if all fences should be returned
>>>> + * @fence: the current fence
>>>> + *
>>>> + * Iterate over the fences in a struct dma_resv object without 
>>>> holding the
>>>> + * dma_resv::lock. The RCU read side lock must be hold when using 
>>>> this, but can
>>>> + * be dropped and re-taken as necessary inside the loop. 
>>>> @all_fences controls
>>>> + * if the shared fences are returned as well.
>>>> + */
>>>> +#define dma_resv_for_each_fence_unlocked(obj, cursor, all_fences, 
>>>> fence)    \
>>>> +    for (fence = dma_resv_walk_unlocked(obj, cursor, all_fences, 
>>>> true); \
>>>> +         fence; dma_fence_put(fence),                    \
>>>> +         fence = dma_resv_walk_unlocked(obj, cursor, all_fences, 
>>>> false))
>>>
>>> Has the fact RCU lock can be dropped so there is potential to walk 
>>> over completely different snapshots been discussed?
>>
>> Well that's basically the heart of the functionality. Even without 
>> dropping the RCU lock there can be an restart at any time when the 
>> dma_resv object is modified.
>
> Hm yes.. that's one of the thing which makes me undecided yet whether 
> a generalised helper is desirable. For example i915_gem_busy_ioctl, as 
> converted, is not completely like-for-like. Maybe it is irrelevant for 
> that one, but then the question needs to be answered for all of the 
> replacements.
>
>>
>>> At least if I followed the code correctly - it appears there is 
>>> potential the walk restarts from the start (exclusive slot) at any 
>>> point during the walk.
>>
>> Correct, yes.
>>
>>> Because theoretically I think you could take an atomic snapshot of 
>>> everything (given you have a cursor object) and then release it on 
>>> the end condition.
>>
>> That's what the dma_resv_get_fences() function is good for, yes. This 
>> one returns an array of fences.
>>
>> The key difference is that we need to allocate memory for that which 
>> is at least sometimes not feasible or desired.
>
> Ah true.. dma_resv_list is not reference counted to simply grab it 
> during setup.
>
>> Thanks for the review,
>
> Np, it is intriguing to look at the option of code consolidation. Just 
> need to read more of the series to form a better high level opinion.

Really appreciated, thanks for looking into this.

Regards,
Christian.

>
> Regards,
>
> Tvrtko
>
>> Christian.
>>
>>>
>>> Regards,
>>>
>>> Tvrtko
>>>
>>>> +
>>>>   #define dma_resv_held(obj) lockdep_is_held(&(obj)->lock.base)
>>>>   #define dma_resv_assert_held(obj) 
>>>> lockdep_assert_held(&(obj)->lock.base)
>>>>   @@ -366,6 +399,9 @@ void dma_resv_fini(struct dma_resv *obj);
>>>>   int dma_resv_reserve_shared(struct dma_resv *obj, unsigned int 
>>>> num_fences);
>>>>   void dma_resv_add_shared_fence(struct dma_resv *obj, struct 
>>>> dma_fence *fence);
>>>>   void dma_resv_add_excl_fence(struct dma_resv *obj, struct 
>>>> dma_fence *fence);
>>>> +struct dma_fence *dma_resv_walk_unlocked(struct dma_resv *obj,
>>>> +                     struct dma_resv_cursor *cursor,
>>>> +                     bool first, bool all_fences);
>>>>   int dma_resv_get_fences(struct dma_resv *obj, struct dma_fence 
>>>> **pfence_excl,
>>>>               unsigned *pshared_count, struct dma_fence ***pshared);
>>>>   int dma_resv_copy_fences(struct dma_resv *dst, struct dma_resv 
>>>> *src);
>>>>
>>


  reply	other threads:[~2021-09-15 10:46 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-13 13:16 Deploying new iterator interface for dma-buf Christian König
2021-09-13 13:16 ` [Intel-gfx] " Christian König
2021-09-13 13:16 ` [PATCH 01/26] dma-buf: add dma_resv_for_each_fence_unlocked Christian König
2021-09-13 13:16   ` [Intel-gfx] " Christian König
2021-09-14 10:53   ` Tvrtko Ursulin
2021-09-14 11:25     ` Christian König
2021-09-14 13:07       ` Tvrtko Ursulin
2021-09-15 10:46         ` Christian König [this message]
2021-09-13 13:16 ` [PATCH 02/26] dma-buf: add dma_resv_for_each_fence Christian König
2021-09-13 13:16   ` [Intel-gfx] " Christian König
2021-09-13 13:16 ` [PATCH 03/26] dma-buf: use new iterator in dma_resv_copy_fences Christian König
2021-09-13 13:16   ` [Intel-gfx] " Christian König
2021-09-13 13:16 ` [PATCH 04/26] dma-buf: use new iterator in dma_resv_get_fences v2 Christian König
2021-09-13 13:16   ` [Intel-gfx] " Christian König
2021-09-13 13:16 ` [PATCH 05/26] dma-buf: use new iterator in dma_resv_wait_timeout Christian König
2021-09-13 13:16   ` [Intel-gfx] " Christian König
2021-09-13 13:16 ` [PATCH 06/26] dma-buf: use new iterator in dma_resv_test_signaled Christian König
2021-09-13 13:16   ` [Intel-gfx] " Christian König
2021-09-13 13:16 ` [PATCH 07/26] drm/ttm: use the new iterator in ttm_bo_flush_all_fences Christian König
2021-09-13 13:16   ` [Intel-gfx] " Christian König
2021-09-13 13:16 ` [PATCH 08/26] drm/amdgpu: use the new iterator in amdgpu_sync_resv Christian König
2021-09-13 13:16   ` [Intel-gfx] " Christian König
2021-09-13 13:16 ` [PATCH 09/26] drm/amdgpu: use new iterator in amdgpu_ttm_bo_eviction_valuable Christian König
2021-09-13 13:16   ` [Intel-gfx] " Christian König
2021-09-13 13:16 ` [PATCH 10/26] drm/msm: use new iterator in msm_gem_describe Christian König
2021-09-13 13:16   ` [Intel-gfx] " Christian König
2021-09-13 13:16 ` [PATCH 11/26] drm/radeon: use new iterator in radeon_sync_resv Christian König
2021-09-13 13:16   ` [Intel-gfx] " Christian König
2021-09-13 13:16 ` [PATCH 12/26] drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies Christian König
2021-09-13 13:16   ` [Intel-gfx] " Christian König
2021-09-13 13:16 ` [PATCH 13/26] drm/i915: use the new iterator in i915_gem_busy_ioctl Christian König
2021-09-13 13:16   ` [Intel-gfx] " Christian König
2021-09-14 13:18   ` Tvrtko Ursulin
2021-09-13 13:16 ` [PATCH 14/26] drm/i915: use the new iterator in i915_sw_fence_await_reservation Christian König
2021-09-13 13:16   ` [Intel-gfx] " Christian König
2021-09-13 13:16 ` [PATCH 15/26] drm/i915: use the new iterator in i915_request_await_object Christian König
2021-09-13 13:16   ` [Intel-gfx] " Christian König
2021-09-14 10:26   ` Tvrtko Ursulin
2021-09-14 10:39     ` Christian König
2021-09-14 10:59       ` Tvrtko Ursulin
2021-09-13 13:16 ` [PATCH 16/26] drm/i915: use new iterator in i915_gem_object_wait_reservation Christian König
2021-09-13 13:16   ` [Intel-gfx] " Christian König
2021-09-13 13:16 ` [PATCH 17/26] drm/i915: use new iterator in i915_gem_object_wait_priority Christian König
2021-09-13 13:16   ` [Intel-gfx] " Christian König
2021-09-14 12:42   ` Tvrtko Ursulin
2021-09-13 13:16 ` [PATCH 18/26] drm/i915: use new iterator in i915_gem_object_last_write_engine Christian König
2021-09-13 13:16   ` [Intel-gfx] " Christian König
2021-09-14 12:27   ` Tvrtko Ursulin
2021-09-14 12:32     ` Christian König
2021-09-14 12:47       ` Tvrtko Ursulin
2021-09-15 11:19         ` Christian König
2021-09-13 13:17 ` [PATCH 19/26] drm/i915: use new cursor in intel_prepare_plane_fb Christian König
2021-09-13 13:17   ` [Intel-gfx] " Christian König
2021-09-13 13:17 ` [PATCH 20/26] drm: use new iterator in drm_gem_fence_array_add_implicit Christian König
2021-09-13 13:17   ` [Intel-gfx] " Christian König
2021-09-13 13:17 ` [PATCH 21/26] drm: use new iterator in drm_gem_plane_helper_prepare_fb Christian König
2021-09-13 13:17   ` [Intel-gfx] " Christian König
2021-09-13 13:17 ` [PATCH 22/26] drm/nouveau: use the new iterator in nouveau_fence_sync Christian König
2021-09-13 13:17   ` [Intel-gfx] " Christian König
2021-09-13 13:17 ` [PATCH 23/26] drm/nouveau: use the new interator in nv50_wndw_prepare_fb Christian König
2021-09-13 13:17   ` [Intel-gfx] " Christian König
2021-09-13 13:17 ` [PATCH 24/26] drm/etnaviv: use new iterator in etnaviv_gem_describe Christian König
2021-09-13 13:17   ` [Intel-gfx] " Christian König
2021-09-13 13:17 ` [PATCH 25/26] drm/etnaviv: replace dma_resv_get_excl_unlocked Christian König
2021-09-13 13:17   ` [Intel-gfx] " Christian König
2021-09-13 13:17 ` [PATCH 26/26] dma-buf: nuke dma_resv_get_excl_unlocked Christian König
2021-09-13 13:17   ` [Intel-gfx] " Christian König
2021-09-13 14:25 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/26] dma-buf: add dma_resv_for_each_fence_unlocked Patchwork
2021-09-13 14:57 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4da378ec-0411-aaf5-fb02-e3a18e7175d3@gmail.com \
    --to=ckoenig.leichtzumerken@gmail.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-media@vger.kernel.org \
    --cc=tvrtko.ursulin@linux.intel.com \
    --subject='Re: [Intel-gfx] [PATCH 01/26] dma-buf: add dma_resv_for_each_fence_unlocked' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.