Re: [PATCH] drm/sched: Increase drm_mock_sched_job_wait_finished timeout when CONFIG_HZ=100

[David Gow]

Le 14/09/2026 à 5:03 PM, Philipp Stanner a écrit :
> +Cc Marco
> 
> On Sun, 2026-09-13 at 16:41 +0800, David Gow wrote:
>> The drm_sched_scheduler_overhead_tests tests hardcode a timeout of 5x
>> total_us, and fail if it's exceeded. However, on systems with
>> CONFIG_HZ < 250, this tends to fail.
>>
>> As it's possible to configure many architectures to use 100 Hz (and some,
>> such as UML, hardcode CONFIG_HZ=100), increase the timeout so that the test
>> doesn't fail on these configurations.
>>
>> Fixes: 97ef806a5314 ("drm/sched: Add some scheduling quality unit tests")
>> Signed-off-by: David Gow <david@xxxxxxxxxxxx>
>> ---
>>
>> This failure showed up on UML when testing the addition of CONFIG_DRM to
>> the KUnit 'alltests' config[1]. Ideally, I'd like to see this test fixed
>> (or at least skipped/disabled) on these broken configurations so that the
>> alltests run is clean. (I don't actually run any CONFIG_HZ=100 configs
>> other than UML, but fixing them all is ideal if we can manage it.)
>>
>> If you'd rather a different implementation / magic number, let me know.
>> I picked 15 here as it gave me plenty of leeway: 10 worked most, but not
>> all, of the time under i386 qemu w/ CONFIG_HZ_100, and was fine with UML
>> on this machine.
>>
>> Thanks,
>> -- David
> 
> Thx for the patch. Where are you running the tests and what for, is it
> a CI or other test system?
> 

Yeah, this is generally for KUnit in CI (and, in my case, to make sure
changes to KUnit itself don't regress other tests). But KUnit tests are
also run in several different CI systems, and now on linux-next as well.

In particular, this has been caught up whilst testing adding
CONFIG_DRM=y to the KUnit 'alltests' config, which is used to get a
config which includes as many tests as possible. This is finding some
real issues, so I think it is worthwhile in general.

> 
> So one thing about the unit tests is that they were originally not so
> much intended for being run on all sorts of CIs, but as a development
> tool for the drm_sched devs to have something to move forward with.
> That's in part why they contain "scheduling quality tests".
> 
> That caused some raised eyebrows already because people run these
> lengthy tests in CIs.

Yeah, finding the distinction between KUnit as a useful tool/framework
for writing tests and KUnit as a suite of tests that should be run
automatically is a bit tricky.

Ultimately, it's a judgement call if the benefit of having the test run
more widely (potentially uncovering real issues, or discovering issues
earlier in, e.g, linux-next merges) is worth the effort of making the
test suitably robust against all of the different environments it runs in.

> Maybe what we actually should have is a split of the test suite into
> two parts, where one part covers basic sanity, and the other measures
> scheduling behavior. The former could then be run by CI folks, the
> latter explicitly be discouraged from being run by anyone who is not a
> drm_sched-developer.
> 

That definitely can be done. As-is, the way this is currently handled is
though CONFIG_KUNIT_ALL_TESTS, and through .kunitconfig files.

If you don't want tests to be caught up in automatic systems (other, I
guess, than your own), then removing the 'default KUNIT_ALL_TESTS' (and
'if !KUNIT_ALL_TESTS' from the DRM_SCHED_KUNIT_TEST Kconfig entry is the
simplest way to do it. You could then set CONFIG_DRM_SCHED_KUNIT_TEST=y
(either via a .kunitconfig file or some other means) to run them whilst
doing drm scheduler development in particular.

And, of course, splitting suites up or skipping tests if certain
prerequisites aren't met are both options for keeping tests in the more
general CI pool if you'd like.

Cheers,
-- David

> 
> P.
> 
>>
>> [1]: https://lore.kernel.org/all/20260911-kunit-drm-v1-1-c5c0f18fc7b0@xxxxxxxxxx/
>> ---
>>  drivers/gpu/drm/scheduler/tests/tests_scheduler.c | 11 +++++++++--
>>  1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/scheduler/tests/tests_scheduler.c b/drivers/gpu/drm/scheduler/tests/tests_scheduler.c
>> index 285546a2218f..02c83b5c2189 100644
>> --- a/drivers/gpu/drm/scheduler/tests/tests_scheduler.c
>> +++ b/drivers/gpu/drm/scheduler/tests/tests_scheduler.c
>> @@ -13,6 +13,13 @@
>>   * logic.
>>   */
>>  
>> +/* We need a more generous timeout when CONFIG_HZ=100. */
>> +#if CONFIG_HZ < 250
>> +#define TIMEOUT_MULTIPLIER 15
>> +#else
>> +#define TIMEOUT_MULTIPLIER 5
>> +#endif
>> +
>>  static int drm_sched_scheduler_init(struct kunit *test)
>>  {
>>  	struct drm_mock_scheduler *sched;
>> @@ -88,7 +95,7 @@ static void drm_sched_scheduler_queue_overhead(struct kunit *test)
>>  
>>  	/* Wait with a safe margin to avoid every failing. */
>>  	done = drm_mock_sched_job_wait_finished(job,
>> -						usecs_to_jiffies(total_us) * 5);
>> +						usecs_to_jiffies(total_us) * TIMEOUT_MULTIPLIER);
>>  	end = ktime_get();
>>  	KUNIT_ASSERT_TRUE(test, done);
>>  
>> @@ -149,7 +156,7 @@ static void drm_sched_scheduler_ping_pong(struct kunit *test)
>>  
>>  	/* Wait with a safe margin to avoid every failing. */
>>  	done = drm_mock_sched_job_wait_finished(job,
>> -						usecs_to_jiffies(total_us) * 5);
>> +						usecs_to_jiffies(total_us) * TIMEOUT_MULTIPLIER);
>>  	end = ktime_get();
>>  	KUNIT_ASSERT_TRUE(test, done);
>>  
>