This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Test time/tst-cpuclock1.c intermitent failures
- From: Carlos O'Donell <codonell at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- Cc: libc-alpha at sourceware dot org
- Date: Fri, 24 Jan 2020 10:30:15 -0500
- Subject: Re: [RFC] Test time/tst-cpuclock1.c intermitent failures
- References: <157987065952.20871.5636395108788791350@localhost.localdomain> <8ac623fe-8e73-24ce-e50b-bfd1c6368f7f@linaro.org> <87d0b83mut.fsf@oldenburg2.str.redhat.com>
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)
--
Cheers,
Carlos.