From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) by sourceware.org (Postfix) with ESMTPS id C7DCC3858D39 for ; Tue, 7 Mar 2023 11:57:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C7DCC3858D39 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-ot1-x336.google.com with SMTP id l16-20020a9d4c10000000b006944b17058cso6771626otf.2 for ; Tue, 07 Mar 2023 03:57:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1678190273; 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=CJUcDBO1kLA7YBKCJKMC8/jAe56GcfTNfukVvCxYLG4=; b=IKQbCEKS0adQ/SfS7NOgez0ZV3hCRJKMrCLWJqLI8D3ZO/86ftDbl0UpgfvqbwsmEw RTtGb2YHRrzvlY325ykw1RSGiqMwnHSsZzRBiyrYdShNk18o6dHLBjomX45fpSZhd/r+ Kew3gYdQodWG66oBs3Ekn1rX6vuTNb+QNRmaiTreOuzka0JKfWEPUCm8vO7Y1/uiQf6C evc141mokrqUkh+uEVWcsBpWMkjCn67nEIhjHq1i0+pWga8ZPbXx9OL0UVkB8Jm6sDNE I+hljIxnpTfIdTKcdQbY7wmF8kyKBz+WIu46d1Bw/WMSnAdrcl1XQ84VUyPfRTybhkZJ 17AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678190273; 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=CJUcDBO1kLA7YBKCJKMC8/jAe56GcfTNfukVvCxYLG4=; b=zFbDW3qpJ915smyyYDRUnX392Sp1qu3zUXTvBuLD6VBI7mZp6d08MZIRITdboAMEqa 6ZXem7VAz+cOl9zff3reRyLga0gIpcPZ86m+G4M1Z87hUXJQmu9I3c3EsauBxjNKbtwH ERpqoxvKjZMv0ivXhUamgmpJ6hNDzquGl3y5Ba8cCKKwrI/e7sbZQ2CucwU6R+xOiLgu BQk76qkl7UZdF9iYTqD0IzBZI82rCVIeD20171jyJFjMcKnJHav3iU0rYn/he3l9kOZv dN3h9zH57+TEst8lM39rc/tJltgt2ZtkwSFDKlsqGluGrZxNFwLfKxXx7/kGelKB/Yp1 ljnQ== X-Gm-Message-State: AO0yUKVgf+XIgUPpnQFT5A681ca0ci7VdLJf3RgW3PziXVBsnbIWvOdY kK+pFPJVcprvb6ODbCgERQSdBB0udeSK7P0NJYbskA== X-Google-Smtp-Source: AK7set8za45um/DsZ+B/HBg/utFlKA2hfCLp5U4oG9eqBDbMbCvxgtAxygcmIhehC7Kux3u22xRxpQ== X-Received: by 2002:a05:6830:1f2b:b0:68b:b532:f411 with SMTP id e11-20020a0568301f2b00b0068bb532f411mr6269018oth.27.1678190272966; Tue, 07 Mar 2023 03:57:52 -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 g10-20020a9d618a000000b006864c8043e0sm5181601otk.61.2023.03.07.03.57.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Mar 2023 03:57:52 -0800 (PST) Message-ID: <738d9792-1369-fe02-b4bf-0a3e0207413c@linaro.org> Date: Tue, 7 Mar 2023 08:57:50 -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> <32a9fa9c-2714-9e18-a3e7-bcfc2d61cd87@linaro.org> <87bkl4pyoa.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <87bkl4pyoa.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:51, Florian Weimer wrote: > * Adhemerval Zanella Netto: > >>> 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. > > No, that won't help. I think the crucial aspect for good x86-64 > performance is that by using the time entry point, we tell the kernel > that it does not have to obtain microsecond or millisecond precision. > >>> 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. > > I'm afraid that this will impact logging performance significantly in > some scenarios. Alright, so I think we should close BZ#30200 as wontfix and state it is done for performance reasons.