Re: [Intel-xe] [PATCH v2 07/31] drm/xe: Only try to lock external BOs in VM bind

["Thomas Hellström" <thomas.hellstrom@linux.intel.com>]

On 5/11/23 01:25, Matthew Brost wrote:
> On Tue, May 09, 2023 at 02:29:23PM +0200, Thomas Hellström wrote:
>> On 5/8/23 23:34, Rodrigo Vivi wrote:
>>> On Mon, May 08, 2023 at 01:08:10AM +0000, Matthew Brost wrote:
>>>> On Fri, May 05, 2023 at 02:40:40PM -0400, Rodrigo Vivi wrote:
>>>>> On Mon, May 01, 2023 at 05:17:03PM -0700, Matthew Brost wrote:
>>>>>> Not needed and causes some issues with bulk LRU moves.
>>>>> I'm confused with this explanation and the code below.
>>>>> could you please provide a bit more wording here?
>>>>>
>>>> We only need to try to lock a BO if it external as non-external BOs
>>>> share the dma-resv with the already locked VM. Trying to lock
>>>> non-external BOs caused an issue (list corruption) in an uncoming patch
>> s/uncoming/upcoming/
>>
>> Also it's not clear to me how this could fix a list corruption in the bulk
>> LRU moves? I mean, if it's a duplicate lock then it gets removed from the tv
>> list and not touched again? Could you explain the mechanism of the fix?
>>
> I had my head wrappeed around this at one point but now I forget as I
> coded this one a while ago. This changes later series (drm_exec
> locking), so IMO not that big of a deal merge this along with the
> following patch without further explaination but if you think it is a
> huge deal I can try to figure out what the issue is again or another
> option is just stage the LRU patch after drm_exec.
>
> Open to whatever but prefer to leave as is.

Since this will be part of a bulk LRU series, separate from drm_exec 
then yes please add an explanation as why this is needed, as we can't 
make something dependent on a future patch that may or may not go in 
depending on the review outcome.

Could also consider reordering so that drm_exec goes in before bulk LRU?

/Thomas

>
> Matt
>
>> Thanks,
>>
>> Thomas
>>
>>
>>>> which adds bulk LRU move. Since this code isn't needed, remove it.
>>> it makes more sense now. with this in commit msg (but with Christopher fix)
>>>
>>>
>>> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
>>>
>>>
>>>> ^^^ How about this.
>>>>
>>>>>> Signed-off-by: Matthew Brost <mattthew.brost@intel.com>
>>>>>> ---
>>>>>>    drivers/gpu/drm/xe/xe_vm.c | 8 +++++---
>>>>>>    1 file changed, 5 insertions(+), 3 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c
>>>>>> index 272f0f7f24fe..6c427ff92c44 100644
>>>>>> --- a/drivers/gpu/drm/xe/xe_vm.c
>>>>>> +++ b/drivers/gpu/drm/xe/xe_vm.c
>>>>>> @@ -2064,9 +2064,11 @@ static int vm_bind_ioctl(struct xe_vm *vm, struct xe_vma *vma,
>>>>>>    		 */
>>>>>>    		xe_bo_get(vbo);
>>>>>> -		tv_bo.bo = &vbo->ttm;
>>>>>> -		tv_bo.num_shared = 1;
>>>>>> -		list_add(&tv_bo.head, &objs);
>>>>>> +		if (!vbo->vm) {
>>>>>> +			tv_bo.bo = &vbo->ttm;
>>>>>> +			tv_bo.num_shared = 1;
>>>>>> +			list_add(&tv_bo.head, &objs);
>>>>>> +		}
>>>>>>    	}
>>>>>>    again:
>>>>>> -- 
>>>>>> 2.34.1
>>>>>>