[PATCH v2 2/5] drm/scheduler: Add scheduler unit testing infrastructure and some basic tests

[Tvrtko Ursulin]

On 04/03/2025 12:29, Philipp Stanner wrote:

[snip]

>>>>>> +struct drm_mock_scheduler *drm_mock_new_scheduler(struct
>>>>>> kunit
>>>>>> *test)
>>>>>> +{
>>>>>> +	struct drm_sched_init_args args = {
>>>>>> +		.ops		= &drm_mock_scheduler_ops,
>>>>>> +		.num_rqs	= DRM_SCHED_PRIORITY_COUNT,
>>>>>> +		.credit_limit	= U32_MAX,
>>>>>> +		.hang_limit	= UINT_MAX,
>>>
>>> Another question – I think we are in the process of deprecating the
>>> hang limit since submitting the same broken job again and again and
>>> expecting it suddenly to work is the classic definition of madness.
>>>
>>> My feeling would be that it should be 1, since that is what we
>>> expect
>>> drivers to do.
>>>
>>> Or is there a specific reason why you set it to MAX anyways?
>>
>> No special reason and it doesn't matter really. It will only be
>> interesting once we add more detailed tests for timeout/ban handling,
>> at
>> which point those tests will explicitly confiture what limit they
>> want.
>> As such, for now, this only needs to be non-zero.
> 
> OK, then I'd say please set it to 1. This way we cannot forget later
> and the scheduler will always behave as we want it to for all drivers.
> 
> I assume it will be a while until we really can remove the hang_limit
> from our code base, so…

Oops I just sent v3 before seeing this. But even so, I was even wrong, 
hang_limit can even be zero. Current code does not exercise that code 
path at all.

I propose we leave it as is now, and then, as we spend time adding more 
tests, we will see how the mock framework will evolve. Until then I 
really do not think it makes sense to give much meaning to the number 
set in there.

Regards,

Tvrtko