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
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
the expected clock_gettime delta and add an explanation about
potentially scheduling pressuring.