Re: [RFC] Test time/tst-cpuclock1.c intermitent failures

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 24/01/2020 09:57, Lucas A. M. Magalhaes wrote:
> The time/tst-cpuclock1.c test fails if running with a high "nice" value
> and there are other loads competing for CPU.
> 
> First of all, I fail to understand the purpose of this test.  It seems
> to me that it's a realtime test as It expects times that are reasonable
> for realtime applications. Indeed it was moved from rt/ to time/.  So,
> What is this testing?  And why was it moved to time/?

It tests the 'clock_getcpuclockid' and the idea is to check if a CPu timer
of a cpu bounded process is correctly obtained with clock_gettime within
a expected bound range.

However since the interface returns the CLOCK_PROCESS_CPUTIME_ID clockid 
of the target pid, its result is subject of scheduling pressure. It means
that even with priority boosting, incorrect results might happen depending
of the system load. 

It was move from rt/ to time/ because the symbol was moved from librt to
libc.

> 
> Following, In my attempted to fix it I tried to amortize the fail rate.
> So, I tried running the sensible code multiple times and look for 70%
> success rate.  However this completely failed as well.  In my first test
> with some CPU load it failed.  I will appreciate suggestions of
> solution.
> 

I think to get reliable results on such test we will need to use a schedule
with different guarantees. For instance, SCHED_DEADLINE with a deadline of
X, Deadline of Y (Y >> X) and a even longer period to not interfere with the
parent probing. But it would require a 3.14 kernel and privileged access.

Maybe one option would to relax the time delta between the two clock_gettime
probes to check for values 0s <= 0.5s and maybe if SCHED_DEADLINE is 
available use a more timing check.