Hi Michal,
On Fri, Jul 04, 2025 at 10:59:15AM +0200, Michal Koutný wrote:
On Fri, Jul 04, 2025 at 03:49:58PM +0900, Shashank Balaji shashank.mahadasyam@sony.com wrote:
- We don't need to separately check user_usec because it'll always be
less than user_usec^W usage_usec, and usage_usec is what's directly affected by throttling.
When kernel is not preemptible, I'd expect the system time may more easily excess the quota, so I considered the user_usage check less prone to false results. But...
- I changed the >= to > because, not that it'll ever happen, but we can
let usage_usec = expected_usage_usec pass. Afterall, it's called "expected" for a reason.
Hmm, here is something interesting. The following patch adds printfs to the existing code to see what user_usec, usage_usec, the expected_usage_usec used in the code, and the theoretical expected_usage_usec are. On running the modified test a couple of times, here is the output:
...thanks for checking. I was misled by the previous test implementation (the expected_usage_usec had no relation to actual throttled usage in there). What you observe is thus likely explained by the default sched_cfs_bandwidth_slice (5 times the tested quota) and CONFIG_HZ.
So I'd say keep only the two-sided tolerant check. (I want to avoid the test to randomly fail when there's no gaping issue.)
Yep, patch v2 is doing just that. So, I assume I have your Acked-by?
Thanks
Shashank