From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x2d.google.com (mail-oa1-x2d.google.com [IPv6:2001:4860:4864:20::2d]) by sourceware.org (Postfix) with ESMTPS id 0F2403857005 for ; Wed, 27 Jul 2022 11:16:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0F2403857005 Received: by mail-oa1-x2d.google.com with SMTP id 586e51a60fabf-10e615a36b0so658210fac.1 for ; Wed, 27 Jul 2022 04:16:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:organization:in-reply-to :content-transfer-encoding; bh=kRqH6+WFnMVLMpeyStAA5wJop51iueZR1Jx+DTN8DMM=; b=rHCxEIT9qAr5qi2RgHWqTQgflXHtweUdGR+tWgjo8LwmNDkgrOJedxHbQ4Th1zffpR pwpLYDpouoe+IXvd2y/azw4XNArffo3fXqRm7W87JhIWhuu9Zesg30mVdxfuiptCE8Jv e0Gd5P5g/qy8zpgfkdOMk7ZiKKBCGoXiKlUox0V3REo0FPWX0xu+X+/YpZ8ePJOK1ztd LYXS+SX+3Ivw2hzOxoHp26WqWq+KulcDluedonGbezaR8I8QBxuAPHr0yM5BioQT1o0A umJ6VnzNxBhOy+RCtacvcd6QWAKE3RyRHomaoSDIUj74wk2Cnsz5PnPMxCUvh29AxPML auPw== X-Gm-Message-State: AJIora8uUpy7djurOU2w5pwRmRAr/dpa3aFryp0B+bzRx5ZdsiPEA4lY LiebMKCJ8x1EMKu7/Yj/NDyZgpwHH25UNQ== X-Google-Smtp-Source: AGRyM1tFhqPEnQi0qG7gl9MBR78dplCp0zth2n7HMtaeSeMunhfeTF9/r1m5EFp+9SZ0ToJS2LvNWQ== X-Received: by 2002:a05:6870:fb8b:b0:10d:ad84:aa56 with SMTP id kv11-20020a056870fb8b00b0010dad84aa56mr1813226oab.294.1658920580241; Wed, 27 Jul 2022 04:16:20 -0700 (PDT) Received: from ?IPV6:2804:431:c7cb:8ded:8925:49f1:c550:ee7d? ([2804:431:c7cb:8ded:8925:49f1:c550:ee7d]) by smtp.gmail.com with ESMTPSA id v15-20020a056870708f00b0010e3f390ecasm1758294oae.16.2022.07.27.04.16.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 Jul 2022 04:16:19 -0700 (PDT) Message-ID: Date: Wed, 27 Jul 2022 08:16:17 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.0.3 Subject: Re: [PATCH v7 07/13] LoongArch: Linux Syscall Interface Content-Language: en-US To: WANG Xuerui , caiyinyu , libc-alpha@sourceware.org, joseph_myers@mentor.com, carlos@redhat.com References: <20220719012056.1461897-1-caiyinyu@loongson.cn> <20220719012056.1461897-8-caiyinyu@loongson.cn> <325a80f2-3010-c93d-8962-4919ca67de43@xen0n.name> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <325a80f2-3010-c93d-8962-4919ca67de43@xen0n.name> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.8 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 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, 27 Jul 2022 11:16:23 -0000 On 27/07/22 02:32, WANG Xuerui wrote: > On 2022/7/27 13:27, WANG Xuerui wrote: >> Wait. I almost missed this, glad I took an extra look before starting afternoon's $DAY_JOB work... >> >> On 2022/7/19 09:20, caiyinyu wrote: >>> |+#define VDSO_NAME "LINUX_2.6" +#define VDSO_HASH 61765110| >> >> |According to Linux sources [1], this should be "LINUX_5.10" instead, and the hash should be 182947696. The current value is for the old world and will lead to the vDSO being essentially wasted. >> | >> >> |To the Release Manager: do this need a proper patch, or if this can be fixed up in the branch pending inclusion? I can prepare one in short order if that's the proper way. >> | >> >> |[1]: https://github.com/torvalds/linux/blob/v5.19-rc8/arch/loongarch/vdso/vdso.lds.S#L59 >> | >> >> > Ah. I just saw the branch merged in master. > > But a quick vdsotest shows the libc version's performance on par with correct vDSO calls: > > clock-gettime-monotonic: syscall: 183 nsec/call > clock-gettime-monotonic:    libc: 44 nsec/call > clock-gettime-monotonic:    vdso: 34 nsec/call > clock-getres-monotonic: syscall: 152 nsec/call > clock-getres-monotonic:    libc: 19 nsec/call > clock-getres-monotonic:    vdso: 14 nsec/call > clock-gettime-monotonic-coarse: syscall: 172 nsec/call > clock-gettime-monotonic-coarse:    libc: 39 nsec/call > clock-gettime-monotonic-coarse:    vdso: 29 nsec/call > clock-getres-monotonic-coarse: syscall: 154 nsec/call > clock-getres-monotonic-coarse:    libc: 18 nsec/call > clock-getres-monotonic-coarse:    vdso: 14 nsec/call > clock-gettime-monotonic-raw: syscall: 181 nsec/call > clock-gettime-monotonic-raw:    libc: 45 nsec/call > clock-gettime-monotonic-raw:    vdso: 36 nsec/call > clock-getres-monotonic-raw: syscall: 151 nsec/call > clock-getres-monotonic-raw:    libc: 19 nsec/call > clock-getres-monotonic-raw:    vdso: 14 nsec/call > clock-gettime-tai: syscall: 187 nsec/call > clock-gettime-tai:    libc: 44 nsec/call > clock-gettime-tai:    vdso: 34 nsec/call > clock-getres-tai: syscall: 151 nsec/call > clock-getres-tai:    libc: 19 nsec/call > clock-getres-tai:    vdso: 14 nsec/call > clock-gettime-boottime: syscall: 184 nsec/call > clock-gettime-boottime:    libc: 44 nsec/call > clock-gettime-boottime:    vdso: 34 nsec/call > clock-getres-boottime: syscall: 151 nsec/call > clock-getres-boottime:    libc: 19 nsec/call > clock-getres-boottime:    vdso: 14 nsec/call > clock-gettime-realtime: syscall: 181 nsec/call > clock-gettime-realtime:    libc: 44 nsec/call > clock-gettime-realtime:    vdso: 34 nsec/call > clock-getres-realtime: syscall: 151 nsec/call > clock-getres-realtime:    libc: 19 nsec/call > clock-getres-realtime:    vdso: 14 nsec/call > clock-gettime-realtime-coarse: syscall: 179 nsec/call > clock-gettime-realtime-coarse:    libc: 40 nsec/call > clock-gettime-realtime-coarse:    vdso: 29 nsec/call > clock-getres-realtime-coarse: syscall: 154 nsec/call > clock-getres-realtime-coarse:    libc: 18 nsec/call > clock-getres-realtime-coarse:    vdso: 14 nsec/call > getcpu: syscall: 134 nsec/call > getcpu:    libc: 20 nsec/call > getcpu:    vdso: 13 nsec/call > gettimeofday: syscall: 171 nsec/call > gettimeofday:    libc: 47 nsec/call > gettimeofday:    vdso: 33 nsec/call > > Which is getting interesting. (This may explain why nobody noticed before the merge.) I think we should still "fix" it, but at this point I'm starting to doubt whether it's a problem in the first place... > So does it this need to be fixed in the end? The numbers indicates that vDSO is indeed being used.