]> git-server-git.apps.pok.os.sepia.ceph.com Git - ceph.git/commit
qa/standalone/ceph-helpers.sh: Thinner resolution in get_timeout_delays()
authorErwan Velu <erwan@redhat.com>
Thu, 7 Jun 2018 13:56:45 +0000 (15:56 +0200)
committerErwan Velu <erwan@redhat.com>
Mon, 25 Jun 2018 20:09:14 +0000 (22:09 +0200)
commit7b0d1c8b8acff2a7010bfb0400df09786033ac63
tree4c560692aa93709e5c7154c436202769216d114c
parentd038e1da7a6c9b31ba4463b8ebedb9908981a55e
qa/standalone/ceph-helpers.sh: Thinner resolution in get_timeout_delays()

get_timeout_delays() is a generic function to compute delays for a long
period of time without saturating the CPU is busy loops.

It works pretty fine when the delay is short like having the following
series when requesting a 20seconds timeout : "0.1 0.2 0.4 0.8 1.6 3.2 6.4 7.3 ".
Here the maximum between two loops is 7.3 which is perfectly fine.

When the timeout reaches 300sec, the same code produces the following
series : "0.1 0.2 0.4 0.8 1.6 3.2 6.4 12.8 25.6 51.2 102.4 95.3 "
In such example there is delays which are nearly 2 minutes !

That is not efficient as the expected event, between two loops, could
arrive just after this long sleep occurs making a minute+ sleep for
nothing. On a local system that could be ok while on a CI, if all jobs
run like CI the overall is pretty unefficient by generating useless CPU
waits.

This patch is about adding a maximum acceptable delay time between two
loops while keeping the same rampup behavior.

On the same 300 seconds delay example, with MAX_TIMEOUT set to 10, we
now have the following series: "0.1 0.2 0.4 0.8 1.6 3.2 6.4 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 7.3"
We can see that the long 12/25/51/102/95 values vanished and being
replaced by a series of 10 seconds. It's up to every test defining the
probability of having a soonish event to complete.

The MAX_TIMEOUT is set to 15seconds.
Signed-off-by: Erwan Velu <erwan@redhat.com>
qa/standalone/ceph-helpers.sh