From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 869D4C433E0 for ; Wed, 1 Jul 2020 20:30:50 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5A3722071A for ; Wed, 1 Jul 2020 20:30:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="PqldXKw/"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="0sLJdW98" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5A3722071A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:Message-Id:Date:Subject:To:From: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Owner; bh=OULCg6OCkS7+Trmn0EsxKglkA47vu18zHkO8z7NBCEc=; b=PqldXKw/2H8nMtGHa8keMlOkpy xSS8CO8LB06LbZM0xNhi35e5Lp3hI5fZb2dQm+GcOd0TsCu6bh5qzd0SPB2OMQmLXPsQfTJPC6aLH vH8hwoOcuYG3W+4ku2hbbUArOKFT0oP1/C6o5RxaZ3PRK3r/4wGfbc6wHEULnRhc3dfdp/UFPxUhb 9t7JmRdexNfcA/NWo5ojYfTyTHLQZ0sDXsskJDM8Ffok3Kg+xvdbBHAx/wm5/ewh9z33248ca/BfA 3ctTOe9yZEmXEERkxLKBN/V1cfOrH1PgFh4aTdl25RD5Dh2BxGIiq8zbX6cT563nfVNjJDqE2oDat 3KbIdBeg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jqjLv-0004UV-TC; Wed, 01 Jul 2020 20:29:07 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jqjLt-0004Tt-0l for linux-arm-kernel@lists.infradead.org; Wed, 01 Jul 2020 20:29:05 +0000 Received: from localhost (fw-tnat.cambridge.arm.com [217.140.96.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 25DE62071A; Wed, 1 Jul 2020 20:29:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593635343; bh=Kxk0d3EHZpscOcNXBInph6glRSx6Wd+ICXCiHY7E404=; h=From:To:Cc:Subject:Date:From; b=0sLJdW98XYAFFe0z07wpMErrL71hAhfffvRmTVp84nU7RhhOZ60VKJBTAyCVznd6j mcI+jzE4IX0WN0CsCGfLyK5yj6qVGW9FdpzyujMy7nsdCkRHPiJ96zNMpGtoP/MvMt cN2XtHIQ6a7DgUHAikBGBufurGhq/Kvdn6/esaNQ= From: Mark Brown To: Catalin Marinas , Will Deacon , Marc Zyngier Subject: [PATCH v2 00/11] arm64: vdso: getcpu() support Date: Wed, 1 Jul 2020 21:28:35 +0100 Message-Id: <20200701202846.54648-1-broonie@kernel.org> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200701_162905_196394_0A706C2F X-CRM114-Status: GOOD ( 21.16 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Brown , Andrei Vagin , Vincenzo Frascino , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org This series is a rebase of the previously posted getcpu() support with some additional patches 5-10 added which try to do some cleanups and clarifications of the vDSO code and extend it to multi-page support. Those patches are currently drafts and haven't been fully tested or considered, they're posted as there was some discussion of other applications of the per-CPU data so it seemed useful to share this in progress work. Some applications, especially tracing ones, benefit from avoiding the syscall overhead for getcpu() so it is common for architectures to have vDSO implementations. Add one for arm64, using TPIDRRO_EL0 to pass a pointer to per-CPU data rather than just store the immediate value in order to allow for future extensibility. It is questionable if something TPIDRRO_EL0 based is worthwhile at all on current kernels, since v4.18 we have had support for restartable sequences which can be used to provide a sched_getcpu() implementation with generally better performance than the vDSO approach on architectures which have that[1]. Work is ongoing to implement this for glibc: https://lore.kernel.org/lkml/20200527185130.5604-3-mathieu.desnoyers@efficio +s.com/ but is not yet merged and will need similar work for other userspaces. The main advantages for the vDSO implementation are the node parameter (though this is a static mapping to CPU number so could be looked up separately when processing data if it's needed, it shouldn't need to be in the hot path) and ease of implementation for users. This is currently not compatible with KPTI due to the use of TPIDRRO_EL0 by the KPTI trampoline, this could be addressed by reinitializing that system register in the return path but I have found it hard to justify adding that overhead for all users for something that is essentially a profiling optimization which is likely to get superceeded by a more modern implementation - if there are other uses for the per-CPU data then the balance might change here. There is some overlap with an in flight patch series from Andrei Vagin supporting time namespaces in the vDSO, there shouldn't be a fundamental issue integrating the two serieses. This builds on work done by Kristina Martsenko some time ago but is a new implementation. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d7822b1e24f2df5df98c76f0e94a5416349ff759 v2: - Rebase on v5.8-rc3. - Add further cleanup patches & a first draft of multi-page support. Mark Brown (11): arm64: vdso: Provide a define when building the vDSO arm64: vdso: Add per-CPU data arm64: vdso: Initialise the per-CPU vDSO data arm64: vdso: Add getcpu() implementation arm64: vdso: Remove union in declaration of the data store arm64: vdso: Document and verify alignment of vDSO text arm64: vdso: Rename vdso_pages to vdso_text_pages arm64: vdso: Simplify pagelist allocation arm64: vdso: Parameterise vDSO data length assumptions in code arm64: vdso: Support multiple pages of vDSO data selftests: vdso: Support arm64 in getcpu() test arch/arm64/include/asm/processor.h | 12 +- arch/arm64/include/asm/vdso.h | 11 ++ arch/arm64/include/asm/vdso/datapage.h | 54 +++++++++ arch/arm64/kernel/process.c | 26 +++- arch/arm64/kernel/vdso.c | 112 ++++++++++++------ arch/arm64/kernel/vdso/Makefile | 4 +- arch/arm64/kernel/vdso/vdso.lds.S | 3 +- arch/arm64/kernel/vdso/vgetcpu.c | 48 ++++++++ .../testing/selftests/vDSO/vdso_test_getcpu.c | 10 ++ 9 files changed, 229 insertions(+), 51 deletions(-) create mode 100644 arch/arm64/include/asm/vdso/datapage.h create mode 100644 arch/arm64/kernel/vdso/vgetcpu.c base-commit: 9ebcfadb0610322ac537dd7aa5d9cbc2b2894c68 -- 2.20.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel