This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

Thanks,
Lucas Magalhães


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]