Merged,
Maxim.
On 03/01/16 04:25, Bill Fischofer wrote:
OK, thanks for the explanation. With that:
Reviewed-by: Bill Fischofer <[email protected]
<mailto:[email protected]>>
On Mon, Feb 29, 2016 at 4:22 PM, Ivan Khoronzhuk
<[email protected] <mailto:[email protected]>> wrote:
On 29.02.16 23:39, Bill Fischofer wrote:
On Mon, Feb 29, 2016 at 11:49 AM, Ivan Khoronzhuk
<[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>> wrote:
For some systems sensitive to time deviation, would be better
to have some time backup while testing scheduler time, so
increase
it to 3 jiffies.
https://bugs.linaro.org/show_bug.cgi?id=2076
Signed-off-by: Ivan Khoronzhuk <[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>
---
test/validation/scheduler/scheduler.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/test/validation/scheduler/scheduler.c
b/test/validation/scheduler/scheduler.c
index dcf01c0..cb04209 100644
--- a/test/validation/scheduler/scheduler.c
+++ b/test/validation/scheduler/scheduler.c
@@ -48,7 +48,7 @@
#define CHAOS_NDX_TO_PTR(n) ((void *)(uintptr_t)n)
#define CHAOS_WAIT_FAIL (5 * ODP_TIME_SEC_IN_NS)
-#define ODP_WAIT_TOLERANCE (20 * ODP_TIME_MSEC_IN_NS)
+#define ODP_WAIT_TOLERANCE (60 * ODP_TIME_MSEC_IN_NS)
Do we know that this is a fix or is it just a guess at a
"better" number?
It's based on jiffy. It definitely should pass for "normal"
platforms w/o impact of Linux scheduler.
As we cannot predict the load on system better to have backup,
practice says that 1 jiffy is not enough in some cases.
The original code used unconditional waits.
If the concern is simply to avoid the possibility of
indefinite stalls then why try to cut things so close?
Nope. Intention here not simply catch indefinite stalls, the
intention to check if time sense for scheduler is working in
normal ranges.
It can differ greatly in case of some incorrect initialization or
calculation. This test is going to catch this.
Actually, the test caught this bug, this bug is not a bug of test,
it's bug of linux-generic implementation when scheduler timeout is
corrupted
with LK scheduler and it's nice to see this captured here. In the
same way it's going to catch issues on "real" boards, where such
huge impact can
be only in case of incorrect timings.
We could agree that a wait of one minute is sufficient to say
that something definitely isn't right, but do we care what
sort of jitter we may see on a run-by-run basis here?
1 minute is a very huge amount of time. Here I just increased it
from 20ms on 5seconds to 60ms on 5seconds. Does it a very small
error? It's about 1.2%.
But it's not based on percentage currently, it's based on slices
the linux kernel scheduler splits time, if you want it can be
bound with 10% error for instance.
I cannot test and predict this value, no one can, which delays can
be on non real time systems.
If platform cannot pass this test it definitely should improve
it`s timing. For instance, if app decides to wait no more than
100ms, but scheduler waits 150ms, is it normal?
Maybe it's normal for linux-generic, but 50ms of waste time it's
big amount of time for normal cases.
A one minute timeout would mean that tests would always get a
result. Implementations that observe waits of that magnitude
would clearly be in need of investigation while others would
still pass this functional validation. Other tests generate
performance numbers and if scheduling waits are unacceptably
large they'd be better covered in that context.
/* Test global variables */
typedef struct {
--
1.9.1
_______________________________________________
lng-odp mailing list
[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>
https://lists.linaro.org/mailman/listinfo/lng-odp
--
Regards,
Ivan Khoronzhuk
_______________________________________________
lng-odp mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/lng-odp
_______________________________________________
lng-odp mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/lng-odp
