You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The testcase was failing frequenty on virtual machines where the
thresholds were too tight and also on hardware without specialized timer
units so I've revisited the threshold computation and came with this
model:
The threshold per one syscall is computed as a sum of:
250 us - accomodates for context switches, etc.
2 * CLOCK_MONOTONIC resolution - accomodates for granurality of the CLOCK_MONOTONIC
0.1% of the sleep capped on 100ms - which is slack allowed in kernel
Then it's multiplied by the number of iterations.
For hardware without specialized timer units (TSC, HPET and such) the threshold
is dominated by the CLOCK_MONOTONIC precision which is, depending on CONFIG_HZ,
something between 100ms and 10ms.
If hardware has high resolution timers, short sleeps are dominated by context
switches while longer sleeps are much more dominated by the slack.
And finally this all works only if the number of iterations is high enough, we
can still hit outliners otherwise so we add 1500us to the threshold to
compensate for them in a case that number of iterations is small.
Signed-off-by: Cyril Hrubis <[email protected]>
Acked-by: Jan Stancek <[email protected]>
0 commit comments