[LTP] [RFC PATCH] tst_test: Add flags to control runtime scaling in timing sensitive tests

[Li Wang]

On Mon, Jun 23, 2025 at 8:10 PM Li Wang <liwang@redhat.com> wrote:

>
>
> On Mon, Jun 23, 2025 at 7:43 PM Martin Doucha <mdoucha@suse.cz> wrote:
>
>> On 23. 06. 25 11:12, Li Wang via ltp wrote:
>> > Some tests, such as those using fuzzy synchronization or probabilistic
>> triggers
>> > (e.g. preadv203), require sufficient runtime to collect meaningful
>> results.
>> > These tests often rely on thresholds like `fzsync_pair.min_samples`,
>> which must
>> > be met during the runtime window.
>> >
>> > When LTP_RUNTIME_MUL is set to a value < 1.0 (commonly in CI
>> environments),
>> > tests may run for too short a time, failing to gather enough samples and
>> > silently producing false negatives or unstable results.
>> >
>> > This patch introduces the following test flags in `enum tst_flag` to
>> provide
>> > fine-grained control over runtime and timeout scaling:
>> >
>> >    - TST_NO_RUNTIME_MUL:
>> >        Ignore LTP_RUNTIME_MUL and use the original .runtime value.
>> >
>> >    - TST_NO_TIMEOUT_MUL:
>> >        Ignore LTP_TIMEOUT_MUL and use the original .timeout value.
>> >
>> >    - TST_NO_FRACTIONAL_RUNTIME_MUL:
>> >        If LTP_RUNTIME_MUL is less than 1.0, round it up to 1.0 to
>> preserve
>> >        intended test duration.
>>
>> I think it'd make more sense to define a minimal runtime in the LTP
>> library (e.g. 1 second) and allow tests to override the value with
>> tst_test.min_runtime. Then you can apply fractional LTP_RUNTIME_MUL
>> safely to any test.
>>
>
> That has been achieved in
> https://lists.linux.it/pipermail/ltp/2025-June/043960.html.
> which avoids .runtime being rounded to zero with fractional
> LTP_RUNTIME_MUL.
>
> This patch introduces TST_NO_FRACTIONAL_RUNTIME_MUL, mainly to
> solve the problem that some special tests (e.g. fuzzy-lib, preadv203)
> should
> not reduce the runtime during execution. Setting a minimum runtime (e.g. 1
> second)
> does not meet the requirements.
>

Oh, it suddenly dawned on me what you were really suggesting.

Use the default minimum runtime of 1 second, and override it with
an arbitrarily large value if necessary, and ensure that the result of
(runtime * running_mul) is never less than the new .min_runtime value.

This is an elegant approach, thanks!

-- 
Regards,
Li Wang