From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailbox.box.xen0n.name (mail.xen0n.name [115.28.160.31]) by sourceware.org (Postfix) with ESMTPS id 63B053857005 for ; Wed, 27 Jul 2022 13:01:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 63B053857005 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=xen0n.name Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xen0n.name DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xen0n.name; s=mail; t=1658926874; bh=k8EwHgpTPoOvgovYErgXzUZkcQAhyUmToLwn45kCz/8=; h=Date:Subject:To:References:From:In-Reply-To:From; b=qYHxPJlIDX9/VGUUaJ8KvC7CEJrQHEu7DF1lL7dBzfBB6BLYR6O46y1EWVZnEBnOy JLlKGVDcq2jxjy/CbpNakcEKJbv0cs4lZ7kae28m6r9aU2y1zUGRez/HIbxBx7b3s2 r2+SItX78uM8Tsoig92IoohNvVTa0mQxERFGyXDg= Received: from [100.100.57.219] (unknown [220.248.53.61]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailbox.box.xen0n.name (Postfix) with ESMTPSA id 9DD1B60610; Wed, 27 Jul 2022 21:01:14 +0800 (CST) Message-ID: Date: Wed, 27 Jul 2022 21:01:14 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:105.0) Gecko/20100101 Thunderbird/105.0a1 Subject: Re: [PATCH v7 07/13] LoongArch: Linux Syscall Interface Content-Language: en-US To: Adhemerval Zanella Netto , 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: WANG Xuerui In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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, 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 13:01:21 -0000 On 2022/7/27 19:16, Adhemerval Zanella Netto wrote: > > 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. If striving for purity, the bug should definitely get fixed, but again I saw in sysdeps/unix/sysv/linux/dl-vdso.h that the dl_vdso_vsym makes use of dl_lookup_symbol_x, which states in its docstring: > Search loaded objects' symbol tables for a definition of the symbol UNDEF_NAME, perhaps with a requested version for the symbol. I dug a little deeper but can't really verify the "perhaps" part, but judging from the doc alone the current behavior may well be expected. Maybe you or someone else more familiar with the details could enlighten me on this, but indeed vDSO must actually be effective for the order-of-magnitude improvement in numbers, hence the inconsistency should not be adversely affecting normal operation besides being a minor nuisance. We can fix it after 2.36 gets released then.