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

[Waiman Long]

On 3/29/22 23:16, Li Wang wrote:
> 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 successivereadings greater than 50 ms (2): 150
>
> If we decide to go with your suggestion, I think we'd better skip this 
> test on VM.
>
I see. So we really need more tolerance for vm. I am OK with your 
current patch then.

Acked-by: Waiman Long <longman@redhat.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20220330/3ab911e9/attachment-0001.htm>