On Thu, Jul 03, 2025 at 10:41:17AM +0900, Shashank Balaji shashank.mahadasyam@sony.com 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