Re: [PATCH] Loosen the limits of time/tst-cpuclock1.

[Stefan Liebler <stli@linux.ibm.com>]

On 8/31/20 2:59 PM, Florian Weimer wrote:
> * Lucas A. M. Magalhaes:
> 
>> Quoting Florian Weimer via Libc-alpha (2020-08-28 09:29:45)
>>> * Stefan Liebler via Libc-alpha:
>>>
>>>> Starting with the commit 04deeaa9ea74b0679dfc9d9155a37b6425f19a9f "Fix
>>>> time/tst-cpuclock1 intermitent failures" (2020-07-11), this test fails
>>>> quite often on s390x/s390 with one/multiple of those: "before - after"
>>>> / "nanosleep time" / "dead - after" ourside reasonable range.
>>>
>>> How much value do these cpuclock tests actually have?  Maybe we should
>>> just remove them, given that their test objective is so difficult to
>>> model in current execution environments.
>>
>> AFAICS this test was moved from rt/ to time/ when the clock_* functions
>> were migrated to libc.so. IMHO this test lost it's purpose during this
>> migration.  I can see why it was needed on rt/, with strict time
>> measures, but on time/ it's just testing clock_* API. I this case I don't
>> see a downside to flex the time requirements.
> 
> The location in the tree does not impact the test objectives.  The move
> was done to reflect that for quite a few releases now, clock_gettime
> has been provided by libc, not librt.
> 
>>> Maybe we could measure clock discontinuities on the CPU-burning thread
>>> and detect CPU stealing this way.  But I'm not sure if this would be
>>> worth it.
>>
>> What we want to achieve with this?
> 
> I think the goal is to ensure that glibc and the kernel agree about the
> definition of the clocks, i.e. that the clock is indeed a CPU time clock
> and does not measure wall-clock time.
> 
> Thanks,
> Florian
> 

Thanks for your comments.

How do we want to proceed here:
- Shall we just loosen the limits?
- Shall we remove the whole test?
- Shall we remove only the first check which compares nanosleep vs
clock_gettime (child_clock, before|after)?

Bye.
Stefan