On Thu, Jul 03, 2025 at 10:41:17AM +0900, Shashank Balaji <[email protected]> wrote: > Going with the more natural way of sticking to CPU_HOG_CLOCK_WALL, the > second patch does calculate expected_usage_usec based on the configured > quota, as the code comment explains. So I'm guessesing we're on the same page > about this?
Yes, the expected_usage_usec in the 2nd patch is correct. (It'd be nicer
if the value calculated from the configured cpu.max and not typed out as
a literal that may diverge should be the cpu.max changed in the test.)
> Do you mean something like,
>
> if (values_close(usage_usec, expected_usage_usec, 10))
> goto cleanup;
>
> using the positive values_close() predicate. If so, I'm not sure I
> understand because if usage_usec and expected_usage_usec _are_ close,
> then we want the test to pass! We should be using the negative
> predicate.
I meant to use it the same way like test_memcontrol.c does, i.e.
values_close() <=> pass.
So codewise it boils down to (a negation, I see why the confusion):
if (!values_close(usage_usec, expected_usage_usec, 10))
goto cleanup;
ret = KSFT_PASS;
Michal
signature.asc
Description: PGP signature
