OK, thanks for the explanation. With that: Reviewed-by: Bill Fischofer <[email protected]>
On Mon, Feb 29, 2016 at 4:22 PM, Ivan Khoronzhuk <[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]>> 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]>> >> --- >> 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]> >> 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
