[LTP] [RFC] Reduce .runtime for Long-Running Tests ?

Petr Vorel pvorel@suse.cz
Tue May 27 13:10:41 CEST 2025


Hi Li,

> Hello All,

> After reviewing some LTP HTML test reports, I noticed that the ten tests
> alone take nearly 20 minutes to complete. For example:

> --------------------
> bind06           300.15s

This uses fuzzy sync, I wonder if it could be speedup. I guess better longer run
than break the test.

> msgstress01      180.44s
> fsx22            170.47s
> pty07            150.04s
> pty06            150.02s
> gf18             121.09s
> gf17             120.82s
> gf16             120.13s
> dirtyc0w_shmem   120.11s
> setsockopt07      76.47s

> In total, running the full ltp-lite suite currently takes ~1h20m, which is a bit
> long for CI or pre-merge validation pipelines.

What is ltp-lite? Is it your internal CI for LTP? bind06 is in cve and syscalls
runtest files.

> I'm wondering whether all these .runtime values are truly necessary to reproduce
> the intended issues (e.g., race conditions, fuzzing, sync timing issues).
> Or if we could:
>  - Set a lower threshold for .runtime on general-purpose stress/fuzz tests

I'd be careful for fuzzy sync.

>  - Introduce a runtime _policy_ for different environments (e.g., fast
> CI vs. full weekly runs)

Or filter out the long running tests if the purpose is just to test LTP itself
instead of the product?

> It might be beneficial to revisit the .runtime values of long-running tests and
> set a minimal yet effective duration that balances reproducibility with resource
> efficiency. This could help save time and free up test resources earlier.

Maybe Martin still have VM's which can trigger the problem to experiment, but
runtime probably differs across architectures and available resources (number of
CPU or memory).

Kind regards,
Petr

> Any thoughts/comments would be appreciated.


More information about the ltp mailing list