From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailbox.box.xen0n.name (mail.xen0n.name [115.28.160.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6E4717B for ; Sat, 18 Jun 2022 12:56:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xen0n.name; s=mail; t=1655557001; bh=+ZJhD3kslwcqzlLuusGRIAUNOBNdrfPLk7bgsPvmgyM=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=O/A93laNcFVV9qGufGs1kJsjLBgInl9e5JS/qk3tY1bDWaqXvA/vi+x4Oio4FwkRn 149Je0XuSCm6ICArEB9ezUDv0oEkzUsPZbYDNFZKwjMTUhgcQz020c+L1lAHSzjB5p D8eHt1xo+SE7BTX9qiZXayfWdB6jyluZVQNX6PqU= Received: from [192.168.9.172] (unknown [101.88.28.48]) (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 ABEF96011F; Sat, 18 Jun 2022 20:56:41 +0800 (CST) Message-ID: <94bebe28-5988-d6b6-bf82-03ef5901cd69@xen0n.name> Date: Sat, 18 Jun 2022 20:56:41 +0800 Precedence: bulk X-Mailing-List: loongarch@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:103.0) Gecko/20100101 Thunderbird/103.0a1 Subject: Re: [PATCH] LoongArch: Add vDSO syscall __vdso_getcpu() Content-Language: en-US To: Huacai Chen , hev Cc: Huacai Chen , Arnd Bergmann , loongarch@lists.linux.dev, linux-arch , Xuefeng Li , Guo Ren , Xuerui Wang , Jiaxun Yang References: <20220617145828.582117-1-chenhuacai@loongson.cn> From: WANG Xuerui In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 6/18/22 17:10, Huacai Chen wrote: > Hi, > > On Fri, Jun 17, 2022 at 11:35 PM hev wrote: >> Hello, >> >> On Fri, Jun 17, 2022 at 10:57 PM Huacai Chen wrote: >>> We test 20 million times of getcpu(), the real syscall version take 25 >>> seconds, while the vsyscall version take only 2.4 seconds. >>> >>> Signed-off-by: Huacai Chen >>> --- >>> arch/loongarch/include/asm/vdso.h | 4 +++ >>> arch/loongarch/include/asm/vdso/vdso.h | 10 +++++- >>> arch/loongarch/kernel/vdso.c | 23 +++++++++----- >>> arch/loongarch/vdso/Makefile | 3 +- >>> arch/loongarch/vdso/vdso.lds.S | 1 + >>> arch/loongarch/vdso/vgetcpu.c | 43 ++++++++++++++++++++++++++ >>> 6 files changed, 74 insertions(+), 10 deletions(-) >>> create mode 100644 arch/loongarch/vdso/vgetcpu.c >>> >>> diff --git a/arch/loongarch/include/asm/vdso.h b/arch/loongarch/include/asm/vdso.h >>> index 8f8a0f9a4953..e76d5e37480d 100644 >>> --- a/arch/loongarch/include/asm/vdso.h >>> +++ b/arch/loongarch/include/asm/vdso.h >>> @@ -12,6 +12,10 @@ >>> >>> #include >>> >>> +typedef struct vdso_pcpu_data { >>> + u32 node; >>> +} ____cacheline_aligned_in_smp vdso_pcpu_data; >>> + >>> /* >>> * struct loongarch_vdso_info - Details of a VDSO image. >>> * @vdso: Pointer to VDSO image (page-aligned). >>> diff --git a/arch/loongarch/include/asm/vdso/vdso.h b/arch/loongarch/include/asm/vdso/vdso.h >>> index 5a01643a65b3..94055f7c54b7 100644 >>> --- a/arch/loongarch/include/asm/vdso/vdso.h >>> +++ b/arch/loongarch/include/asm/vdso/vdso.h >>> @@ -8,6 +8,13 @@ >>> >>> #include >>> #include >>> +#include >>> + >>> +#if PAGE_SIZE < SZ_16K >>> +#define VDSO_DATA_SIZE SZ_16K >> Whether we add members to the vdso data structure or extend >> SMP_CACHE_BYTES/NR_CPUS, the static VDSO_DATA_SIZE may not match, and >> there is no assertion checking to help us catch bugs early. So I >> suggest defining VDSO_DATA_SIZE as ALIGN_UP(sizeof (struct vdso_data), >> PAGE_SIZE). > VSYSCALL usage is very limited (you know, VSYSCALL appears for so many > years, but the number nearly doesn't increase until now), so I think > 16KB is enough in the future. I don't think omitting compile-time assertions for *correctness* is worth the negligible improvement in brevity and ease of maintenance. In fact, static checks for correctness actually *lightens* maintenance burden, by explicitly calling out the assumptions so that newcomers (i.e. me or some other random linux/arch developer refactoring code) would find them very helpful. So I'm in support for declaring the VDSO_DATA_SIZE explicitly in terms of sizeof(struct vdso_data) and PAGE_SIZE.