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
