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

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Fri, Jan 24, 2020 at 8:50 AM Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
>
>
>
> On 24/01/2020 13:46, Lucas A. M. Magalhaes wrote:
> > Quoting Carlos O'Donell (2020-01-24 12:30:15)
> >> On 1/24/20 10:17 AM, Florian Weimer wrote:
> >>> * Adhemerval Zanella:
> >>>
> >>>> 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.
> >>>
> >>> We could move it back to rt.  It might help somewhat because the rt
> >>> tests are serialized.
> >>
> >> I would like to get away from serialized tests, so if we can write this test
> >> to be more robust and take into account the system load or uncertainty, then
> >> that would be a win IMO.
> >>
> >> Any other alternative is costly for the project:
> >> - Run tests serially (bad for developer experience)
> >> - Write our own test scheduler (increases maintenance cost)
> >>
> >
> > I totally agree with Carlos here.  However in the absense of a good
> > solution I find Florians aproach acceptable.  At least we don't have the
> > other tests messing with the result of this one.
>
> But it only masks potential issues if the system load is independent
> of glibc testing. I still think a better solution you just to relax

I agree.  My glibc testing machines are heavily loaded and I saw this
failure all the time.

> the expected clock_gettime delta and add an explanation about
> potentially scheduling pressuring.



-- 
H.J.