From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) by sourceware.org (Postfix) with ESMTPS id 6881138515F9 for ; Wed, 8 Mar 2023 16:57:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6881138515F9 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-oi1-x234.google.com with SMTP id bj30so12657976oib.6 for ; Wed, 08 Mar 2023 08:57:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1678294629; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=7SYqvM9tRLQeJ7d8ic12lbbnzgyZfLRkAJAIyz4c4Cs=; b=pg7WVq3E6qvJhxwxFIB2dpONSDR3tWgdmk6hnIVSOOJOJiXAHu2Nuwi7BVoeJ1mNdB 7YVF1ZUQI238J5IWlfhkq31Y/Hmvh45HlPG5y9ALlrtLJ9geBbKyCJiNOKoNR0IYjr8x Y/EBXadRfT6cEAEQUEOYOJ8siuH4Nh9Q2PE6+wHPjRw+owKxv4XuDbw2dgoVc9XA26Uv jbpg3uIbWGTp+TBE00+a4W+qBAX/KHSk4UjMdPMpdI4+9uMwdtCmOY7wn4rPJziB2kbP FDlqBqGD0OxcyspaSwGeZXqCLT2KtuSLix/7EAWJu59ipG6MUH09WYOfF7nW38A4yAk8 iFbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678294629; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7SYqvM9tRLQeJ7d8ic12lbbnzgyZfLRkAJAIyz4c4Cs=; b=WJ1dOPbBosVUfTz9GkktZSnnUlAMXS7WPcd9wNgW1Yj1mhLbpgdhieyMV8REf0Lh2o r5cornptJ/qYjfM3GSZnEDj8Af+i55AFqIwf9WvMR8oVJCEy6lB9CM6IMQI5cPX7i/OC BHICsqdRlIsvQA3Z84Y/udAUtxWXwhPAnlOUaJ23sT4hcnGBwG977pAYL9BtTIfBvOvW p6kVuOxwxxhpZURFYAdpTVCFfm5JD2gwYfeBgiN9lE+z3k4SNWnWIeYp/Fd03LSQpCDH fTItsRzXvf4QgORsZvrrYM7SjhgeJAzD3J23wLGkjdjiieRuXhtC2tO6R3DB9rK7T1gb 0TvQ== X-Gm-Message-State: AO0yUKV8Oun+NorVNxNhOCBM7Q0G5LNU+CDqKFo5MHWgS/m7jOef8JAg /YN9MpMtt8xyT4gz5WK6ymVsbQ== X-Google-Smtp-Source: AK7set9uc9YBcEV5w2ltkGOBI2hYlvKmUNf10vjNtFBvnNtNSzyJ7dMeb0AHsoYxwPTqh4IaWgDezQ== X-Received: by 2002:a05:6808:5c7:b0:37f:7df1:efde with SMTP id d7-20020a05680805c700b0037f7df1efdemr8352399oij.0.1678294629678; Wed, 08 Mar 2023 08:57:09 -0800 (PST) Received: from ?IPV6:2804:1b3:a7c0:544b:655d:5559:758d:90f7? ([2804:1b3:a7c0:544b:655d:5559:758d:90f7]) by smtp.gmail.com with ESMTPSA id bm40-20020a0568081aa800b0037faba740b8sm6484841oib.16.2023.03.08.08.57.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Mar 2023 08:57:09 -0800 (PST) Message-ID: Date: Wed, 8 Mar 2023 13:57:06 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH] time: Use CLOCK_REALTIME for time (BZ #30200) Content-Language: en-US To: Bruno Haible , Florian Weimer , Paul Eggert Cc: libc-alpha@sourceware.org References: <20230306160321.2942372-1-adhemerval.zanella@linaro.org> <877cvspxxa.fsf@oldenburg.str.redhat.com> <4301180.vrBl8dPDy9@nimes> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <4301180.vrBl8dPDy9@nimes> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 08/03/23 13:23, Bruno Haible wrote: > Paul Eggert wrote: >> My idea is to go through the apps I help maintain, and make sure that >> they never call 'time' anywhere that it's important that a timestamp be >> in sync with with the rest of the system > > Alternatively, these applications can continue to call 'time', if the > package uses the Gnulib module 'time' that provides a workaround against > https://sourceware.org/bugzilla/show_bug.cgi?id=30200 . > > Bruno Florian, do you really think that and latency increase of roughly 15ns is really worth all the trouble gnulib is pushing? It means that we will end up with programs that use CLOCK_REALTIME, while other use CLOCK_REALTIME_COURSE. If users really to squeeze more performance, they can use clock_gettime with CLOCK_REALTIME_COURSE. It should have similar performance to time vDSO.