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=-0.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,FSL_HELO_FAKE, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no 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 F32D2C5519F for ; Mon, 16 Nov 2020 10:19:49 +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 6BC9A20888 for ; Mon, 16 Nov 2020 10:19:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="WmLHXg1F"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="ERR/6n8A" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6BC9A20888 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com 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:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=AfcnyvO6lm8Ujf6IP5Exjg7TulGrENNlDH01pvTMllI=; b=WmLHXg1FboTFvaIoI2dZPwAD7 TciRcb316RmtdkZciqs7uNy2Y/WkKJyZGfDtI229bOIErD1qN6YnEb/79P9kuobetU8BJsDC898FP ZMYcfj3fWb5GzJmU/oQfJfuLi7TvklzyoTqX/vAJm/JYbKSH4B3bv80ouXn/36sP3DZ4sxbArS2eW aUKKBwKnJ+nWrObqg0tGsmaFz8fJhdxvI5tGTXZhwAWIUM6o/QwMhFkYtDafvs1PvM5TuSYL++7kH Keg3YnwoewvpkkI/1qAb0071Ct9bxqhWKw2EaJ/5/c0EVNOR0ceCH3hLPBuU/R4TLSMsh3N0EN9Fk wWv0xXPsQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kebaN-0001D1-Qq; Mon, 16 Nov 2020 10:18:11 +0000 Received: from mail-wr1-x433.google.com ([2a00:1450:4864:20::433]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kebaK-0001An-Rk for linux-arm-kernel@lists.infradead.org; Mon, 16 Nov 2020 10:18:09 +0000 Received: by mail-wr1-x433.google.com with SMTP id s8so18025566wrw.10 for ; Mon, 16 Nov 2020 02:18:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=WwZgehptnleATNiMirLPV50YiTA3eu3qaI0219s/ggQ=; b=ERR/6n8ACvaytrj+SyUlYQi6Gu8tQUQISvu4zkpGfB9vdSnG/etvDMguIaOjIsEzJ6 RhtYGfogW2JBf/12iNIjEI38aWCciDzjvBrefXrgBSTwtbuVr+ZNMW6gszocoE1fiYRd Hi0TSIl9ppPmak87XuFHsGntfLhGX0recTEsIaFxwzBLXu6cFqJwqHdLdiXdwC+mkFoe bdtXrqH4pbQuR1/E19PpkmUm1fX8D+fRe+gDNyQpGMLF7jVEmbJZsRX9auShDXnfTtzV qOEhLcC5HZBOeUFxnadA7rgRiKwxLf/ukRlUA4hK3dwaSkV4RkRl9qVlqbZ0+zikfMk+ v36w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=WwZgehptnleATNiMirLPV50YiTA3eu3qaI0219s/ggQ=; b=T/KbF46m617VVRMFRS8hhGdzbi5ADj4h7vBBBtQb9dsSsFAsKsLYlZH+4oChvXtIFu xlKOlNoNOi69GIND3U/wzQe3GyeUbgSBy1Y8ltFNXXUVYtzttYv6yXbnjsAr8cq0F/Wc b71+5Jjc4AD5aGVLga+MuoLZ1ZviZxo6VfX4XBjfKKF+xXaopsY+jVaLzSBEdHGodDST puwPSmoVJ9e/kEo5QhyiV9EJ/ssyJVPWenLc+/wRaqrzIedMJtTk/HiDtsMfeqIjTPQG bVmi+A2F8cc5KaPiDyGW+9VC7cOPBldc3R/+tnL+6BF6ScXkhy5S8c38zxWJ+V4pYYbv LFtQ== X-Gm-Message-State: AOAM5303CZvSYBHu4r5J6OfemOBUTRQSDxbSQVRiwKGZozXHJTtdBQGC 4EbUW3eaOM39meZOJCBQSo0j2w== X-Google-Smtp-Source: ABdhPJyb9IkKukk28MN31YXWL61dqfqejRVF1BZl720PMguZVRrOL0EBV9Eo2CzWuuW8WeeYA6PucQ== X-Received: by 2002:adf:cf0b:: with SMTP id o11mr18013817wrj.162.1605521885826; Mon, 16 Nov 2020 02:18:05 -0800 (PST) Received: from google.com ([2a00:79e0:d:210:f693:9fff:fef4:a7ef]) by smtp.gmail.com with ESMTPSA id b8sm18499407wmj.9.2020.11.16.02.18.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Nov 2020 02:18:05 -0800 (PST) Date: Mon, 16 Nov 2020 10:18:02 +0000 From: Quentin Perret To: Ard Biesheuvel Subject: Re: [PATCH v2] arm64: implement support for static call trampolines Message-ID: <20201116101802.GA3908597@google.com> References: <20201028184114.6834-1-ardb@kernel.org> <20201029112747.GA4090840@google.com> <20201029115442.GA4092571@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201029115442.GA4092571@google.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201116_051808_974459_A5164136 X-CRM114-Status: GOOD ( 18.57 ) 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 Rutland , Peter Zijlstra , Catalin Marinas , James Morse , Will Deacon , Linux ARM 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 On Thursday 29 Oct 2020 at 11:54:42 (+0000), Quentin Perret wrote: > The reason I'm interested in this is because Android makes heavy use of > trace points/hooks, so any potential improvement in this area would be > welcome. Now I agree we need numbers to show the benefit is real before > this can be considered for inclusion in the kernel. I'll try and see if > we can get something. Following up on this as we've just figured out what was causing performance issues in our use-case. Basically, we have a setup where some modules attach to trace hooks for a few things (e.g. the pelt scheduler hooks + other Android-specific hooks), and that appeared to cause up ~6% perf regression on the Androbench benchmark. The bulk of the regression came from a feature that is currently Android-specific but should hopefully make it upstream (soon?): Control Flow Integrity (CFI) -- see [1] for more details. In essence CFI is a software-based cousin of BTI, which is basically about ensuring the target of an indirect function call has a compatible prototype. This can be relatively easily checked for potential targets that are known at compile-time, but is a little harder when the targets are dynamically loaded, hence causing extra overhead when the target is in a module. Anyway, I don't think any of the above is particularly relevant to upstream just yet, but I figured this would interesting to share. The short-term fix for Android was to locally disable CFI checks around the trace hooks that cause the perf regression, but I think static-calls would be a preferable alternative to that (I'll try to confirm that experimentally). And when/if CFI makes it upstream, then that may become relevant to upstream as well, though the integration of CFI and static-calls is not very clear yet. Thanks, Quentin [1] https://www.youtube.com/watch?v=0Bj6W7qrOOI _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel