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

[Florian Weimer]

* 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