[LTP] [PATCH v2] clock_gettime04: set threshold based on the clock resolution

Li Wang liwang@redhat.com
Wed Mar 30 05:16:43 CEST 2022


Waiman Long <longman@redhat.com> wrote:


The patch looks good in general. However, maybe we should do something like:
>
> diff --git a/clock_gettime04.c b/clock_gettime04.c
> index a8d2c5b..1ba218b 100644
> --- a/clock_gettime04.c
> +++ b/clock_gettime04.c
> @@ -92,11 +92,18 @@ static struct time64_variants variants[] = {
>
>   static void setup(void)
>   {
> +       delta = 5;
>          if (tst_is_virt(VIRT_ANY)) {
>                  tst_res(TINFO, "Running in a virtual machine, multiply
> the delta by 10.");
>                  delta *= 10;
>          }
>
> +       clock_getres(CLOCK_REALTIME, &res);
> +       precise_delta = delta + res.tv_nsec / 1000000;
> +
> +       clock_getres(CLOCK_REALTIME_COARSE, &res);
> +       coarse_delta = delta + res.tv_nsec / 1000000;
> +
>          find_clock_gettime_vdso(&ptr_vdso_gettime, &ptr_vdso_gettime64);
>   }
>
> to avoid a coarse_delta that is too large for vm.
>

Thierically that's right, we only make the resolution as additional value
to tolerate.

But I'm afraid this is the part we can not guarantee especially for VM.
As from Eirik's test history, the KVM guest ever failed with "150ms" delay:
  clock_gettime04.c:163: TFAIL: CLOCK_BOOTTIME(vDSO with old kernel spec):
Difference between successive readings greater than 50 ms (2): 150

If we decide to go with your suggestion, I think we'd better skip this test
on VM.

-- 
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20220330/aa6c9631/attachment-0001.htm>


More information about the ltp mailing list