From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) by sourceware.org (Postfix) with ESMTPS id AD2C13857025 for ; Wed, 23 Jun 2021 13:26:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AD2C13857025 Received: by mail-qk1-x72c.google.com with SMTP id i68so5143676qke.3 for ; Wed, 23 Jun 2021 06:26:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=fDFK03EdmaycCSShAPRAJUYQmXlTqNtQqDMMd1Xv6cw=; b=ENtT5/6bnFqGb1kQTU5a2wP157e1doQbxGfGuCPMjLpDLT48vpfevL1wspHK8fQJ+p XqdivONlvqzhFDVObkeBRPUY46iymSBkDOGeoWjo9yO983iLyxITu9/mTGrJP+R75cif J5WuZg5GEbk3YQAFwFDPXpPnpoUGVEzZiwQGCcRNoaYF3YBpMTwRHLlKpEAxvb+PIGql G48Y0GUBbeW164mKJrGDS9S2LbOQLWPR8eA6lA1DIwYlhediUt8InPC5mTBtUZ+ozmR2 36qCwEn76rmmyPi2K8e+eT2v0N5XpS/q6MtgyhuZw6sCr1G0Pw3dWoeP4mNy+EUIb3pH qVvw== X-Gm-Message-State: AOAM5326hgpzfGwTj03Bh0WrEeTFBpGHQSpVbw5tx7cdS/a+r7/vPTxS r74W1yfS2bcg0lmv3rAVRzFxdA== X-Google-Smtp-Source: ABdhPJxnRGDfHoFstYEgEfCsP4RElL+S9rdIiI2fwm9l3WnfHm7WzJzq6JJV+6Q5lHgELw6IhqhYDA== X-Received: by 2002:ae9:efd8:: with SMTP id d207mr1483041qkg.257.1624454796329; Wed, 23 Jun 2021 06:26:36 -0700 (PDT) Received: from [192.168.1.108] ([177.194.59.218]) by smtp.gmail.com with ESMTPSA id h4sm3882470qti.0.2021.06.23.06.26.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Jun 2021 06:26:36 -0700 (PDT) Subject: Re: aarch64 lacks HP_TIMING support in glibc To: Wilco Dijkstra , 'GNU C Library' , "rafaeleduardoruviaro.christ@asml.com" References: From: Adhemerval Zanella Message-ID: Date: Wed, 23 Jun 2021 10:26:33 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.1 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.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2021 13:26:37 -0000 On 23/06/2021 08:43, Wilco Dijkstra via Libc-alpha wrote: > Hi Rafael, > >> I noticed that aarch64 lacks HP_TIMING support in glibc. Although this architecture has generic timers, glibc is still using the generic hp-timing.h for aarch64. >> I see HP_TIMING support for other architectures. I'd like to know why there is no HP_TIMING support for aarch64? >> Also, if there's planning to support it for aarch64? > > I added HP_TIMING support for all targets a while back - this uses fast timers > via the vDSO mechanism. Some targets also have a header with an inline counter. > > However it's not an external header and it is hardly used inside GLIBC, so it's > not clear whether it's worth the effort to ensure that cntvct_el0 is never trapped > on AArch64 or just declare the systems that do trap it obsolete. > > Cheers, > Wilco > Is the trap really an issue here? Assuming that we can make it only issued for LD_DEBUG=statistics (I need to check if they are used outside it), it will be basically the cost of calling clock_gettime on the architecture without the support.