From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x2a.google.com (mail-oa1-x2a.google.com [IPv6:2001:4860:4864:20::2a]) by sourceware.org (Postfix) with ESMTPS id 8F3503858D39 for ; Tue, 7 Mar 2023 11:45:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8F3503858D39 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-oa1-x2a.google.com with SMTP id 586e51a60fabf-176d93cd0daso5342065fac.4 for ; Tue, 07 Mar 2023 03:45:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1678189509; 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=C8YhMYTSOBByexLw1jquBZq8XjSQmBLXCpWGBsAP6ic=; b=vLqcmpAldiWsbgaj46AQm0tWN+60MgXaF8bxPfMsHkgWj1PX7ISHnCc2U8pT/cdMnC reEQWUjZ3xVa/s1RRkD1fGUjKoGSskN/9ohBdlFuGNQjgVmsRKtXOxfzhKxdbT3fVZga S6jCPOCoheyHGKOn8WclGw1OlMWbQWLXYFJ52FKQGXeZPgYch5Zh8buGuXADzc3yGAXn 96PULGdlQO7ATIkM2ndRJt687t0K89XI8YBWurOP2llnj0Q6kI6zC0+6L+bhoAF3GMHQ QfMEDPUi60XMAGDVgb+QF+On79ySTMPheGAio1XnIk4UQwmH8gjCqQS2zvv2OCT8OHXR lCYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678189509; 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=C8YhMYTSOBByexLw1jquBZq8XjSQmBLXCpWGBsAP6ic=; b=dXqC9X1a8owDZLmo9h3V+mZf2gWubVVox0Napt7drtz58kGfE0kNwjySlNBEnXtdy9 QSamgly7L8k3CKDDoLiOdcuCLy3oRG9nj8qKgU4bKxj4GZWIu6p0zxu+tx6NZ9DQV22i gcKJ1Os1PC7zBAnHi3G9HwczWB6V1LMHmKPO99Px9wdrCjAhUYZoi5aiEsYZDuZsDdZ7 NcJO+2lvF0PhmDN7PBHeICbHjQYSCN5vN462RKI/v84k/rJqoBrQ2AJbCwpCscplkHDF eXyT47wBhTig/GaaygF5eU3W8/rAdZ28w7XX9KHQHRy1xdBdkSvR8wrzyB6NltKO0Hf9 7/HA== X-Gm-Message-State: AO0yUKWzfk3Vtt4tIsJSXTGoyfJXe/bKVn9Dzszs3f2dbxoY9xmWwzbI ifNymXRpkXyGcKlO+JDBdQxwX0k44R653IvSRmWxvg== X-Google-Smtp-Source: AK7set9vGdjKZLraUf8/yI4UGHT5rnCjZ3WruFdXPn4crMUtcIy4LFm2I1+pXMeHl8a2SibZJzGunw== X-Received: by 2002:a05:6870:830b:b0:172:3d71:c248 with SMTP id p11-20020a056870830b00b001723d71c248mr9176186oae.18.1678189508740; Tue, 07 Mar 2023 03:45:08 -0800 (PST) Received: from ?IPV6:2804:1b3:a7c3:d849:85a1:d2e8:5a25:72e7? ([2804:1b3:a7c3:d849:85a1:d2e8:5a25:72e7]) by smtp.gmail.com with ESMTPSA id ea2-20020a056870070200b00176209a6d6asm5031066oab.10.2023.03.07.03.45.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Mar 2023 03:45:08 -0800 (PST) Message-ID: <32a9fa9c-2714-9e18-a3e7-bcfc2d61cd87@linaro.org> Date: Tue, 7 Mar 2023 08:45:05 -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: Florian Weimer Cc: libc-alpha@sourceware.org, Bruno Haible References: <20230306160321.2942372-1-adhemerval.zanella@linaro.org> <87ttywq0je.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <87ttywq0je.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.2 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 07/03/23 08:11, Florian Weimer wrote: > * Adhemerval Zanella: > >> Different than gettimeofday and timespec_get, time uses >> CLOCK_REALTIME_COARSE instead of CLOCK_REALTIME on Linux. The >> coarse time is used mostly as optimization, but it may show >> divergence progression due the clock resolution. >> >> For x86_64 and powerpc64, it should add slight more latency since >> it would call now clock_gettime internally. > > It seems really significant on x86-64. > > Before: > > min: 14 ns > 25%: 16 ns > 50%: 17 ns > 75%: 17 ns > 95%: 18 ns > 99%: 18 ns > max: 18722 ns > avg: 16.6606 ns > > After: > > min: 29 ns > 25%: 31 ns > 50%: 31 ns > 75%: 32 ns > 95%: 32 ns > 99%: 33 ns > max: 12161 ns > avg: 31.2205 ns > > And of those original 17 ns, quite a bit is overhead from the > benchmarking loop. I guess applications could work around it by having > a background timer thread that increments a global variable and use that > instead of the time function call, but that seems not a great approach. Yes, this is expected since time call will be route through clock_gettime. Another fix would be to convince kernels developers to use CLOCK_REALTIME on vDSO as well. > > Based on previous feedback, I expect we'd have to carry a downstream > revert of this patch indefinitely, so I'm rather strongly against > applying it upstrean. To me it really seems like a over-optimization specially because 'time' has only second resolution.