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 3A01F3857BAD for ; Wed, 27 Jul 2022 05:33:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3A01F3857BAD 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=1658899980; bh=X/mNHrBUV8n5rEbXXHM8fH6WzGS13+0t197QW+YwBH4=; h=Date:Subject:To:References:From:In-Reply-To:From; b=JpQf3SHpBfA644EZdRUlggVpFN8147KjRiPgZ5Rtys5UQb/mQZOi2nyDmfY+vKX4q tu2/HduHB1h56iKIVZbt+C4OXLqJ73rFmzGVS7VUbrhcn8C1d/JTT58vl0SA/F9CNM Aw3a5BPsGc00VnPeQbnchZidlV2Q/6KWcJCyg7RY= 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)) (No client certificate requested) by mailbox.box.xen0n.name (Postfix) with ESMTPSA id 4393660610; Wed, 27 Jul 2022 13:33:00 +0800 (CST) Message-ID: <325a80f2-3010-c93d-8962-4919ca67de43@xen0n.name> Date: Wed, 27 Jul 2022 13:32:59 +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: WANG Xuerui , caiyinyu , adhemerval.zanella@linaro.org, libc-alpha@sourceware.org, joseph_myers@mentor.com, carlos@redhat.com References: <20220719012056.1461897-1-caiyinyu@loongson.cn> <20220719012056.1461897-8-caiyinyu@loongson.cn> 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.1 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 05:33:06 -0000 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...