On 13/07/2023 23:25, shaozhengchao wrote:
On 2023/7/14 5:16, Matthieu Baerts wrote:
When looking for something else in LKFT reports [1], I noticed that the TC selftest ended with a timeout error:
not ok 1 selftests: tc-testing: tdc.sh # TIMEOUT 45 seconds
The timeout had been introduced 3 years ago, see the Fixes commit below.
This timeout is only in place when executing the selftests via the kselftests runner scripts. I guess this is not what most TC devs are using and nobody noticed the issue before.
The new timeout is set to 15 minutes as suggested by Pedro [2]. It looks like it is plenty more time than what it takes in "normal" conditions.
Fixes: 852c8cbf34d3 ("selftests/kselftest/runner.sh: Add 45 second timeout per test") Cc: stable@vger.kernel.org Link: https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20230711/tes... [1] Link: https://lore.kernel.org/netdev/0e061d4a-9a23-9f58-3b35-d8919de332d7@tessares... [2] Suggested-by: Pedro Tammela pctammela@mojatatu.com Signed-off-by: Matthieu Baerts matthieu.baerts@tessares.net
tools/testing/selftests/tc-testing/settings | 1 + 1 file changed, 1 insertion(+)
diff --git a/tools/testing/selftests/tc-testing/settings b/tools/testing/selftests/tc-testing/settings new file mode 100644 index 000000000000..e2206265f67c --- /dev/null +++ b/tools/testing/selftests/tc-testing/settings @@ -0,0 +1 @@ +timeout=900
I remember last year when I tested all the tdc cases（qdisc + filter + action + infra） in my vm machine, it took me nearly 20 minutes. So I think it should be more than 1200 seconds if all cases need to be tested.
Maybe we should really optimize the parallel execution process of tdc.
Let's try to spend some cycles improving the tdc code performance first. TDC boils down essentially to: - Setup namespace (if needed) - Setup network interfaces - Spawn a few processes - Match a regex - Bring down namespace
Nothing above screams expensive, so I'm sure there are some low hanging fruits to improve the overall wall time even in debug kernels.