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=-7.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 96280C47092 for ; Wed, 2 Jun 2021 17:56:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7B36661DA7 for ; Wed, 2 Jun 2021 17:56:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230353AbhFBR5u (ORCPT ); Wed, 2 Jun 2021 13:57:50 -0400 Received: from mail.kernel.org ([198.145.29.99]:48346 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229467AbhFBR5t (ORCPT ); Wed, 2 Jun 2021 13:57:49 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 5793661DA5; Wed, 2 Jun 2021 17:56:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1622656566; bh=Czsuka7+HAGaSUNNQSSRfeXG6GJieqJ4DRUlmcntgAY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=t5cJqRiURMB0mvCDuGxAQqoQaubwsosndqXFSMS4MV01Blt3guNQdVa6KgxMskLh/ i+XoodFDYNHcDJfZPFwi2mG6UO2vAdFGvJuPRdFvR0WXkk5njxy4XZTyQMVyTVackS VF4gbeIEAs1034YIdmLym9QTFCge8bFpXghi1epxehKF01pD2JHU7BOgakp0zJ64PB iT0VSbSMOaUA7la2vkc96ulysSfE2XV2lGm9KCB8nzlSsrHQ45AMFOqxgBsUkl/pLN vyTpn801vbDdCAsWGnOUW/pHFTV3SV/xMl8bESrw5wcIrFTaT2xojOOvUSph92qO96 9uEKhbqRyHkdg== Date: Wed, 2 Jun 2021 18:55:59 +0100 From: Will Deacon To: Douglas Anderson Cc: Catalin Marinas , Nick Desaulniers , Seth LaForge , Ricky Liang , Alexander Shishkin , Arnaldo Carvalho de Melo , Ingo Molnar , Jiri Olsa , Mark Rutland , Namhyung Kim , Nathan Chancellor , Peter Zijlstra , clang-built-linux@googlegroups.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org Subject: Re: [PATCH 0/3] arm64: perf: Make compat tracing better Message-ID: <20210602175559.GC31957@willie-the-truck> References: <20210507205513.640780-1-dianders@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210507205513.640780-1-dianders@chromium.org> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Doug, Thanks for posting this, and sorry for the delay in getting to it. On Fri, May 07, 2021 at 01:55:10PM -0700, Douglas Anderson wrote: > The goal for this series is to improve "perf" behavior when 32-bit > userspace code is involved. This turns out to be fairly important for > Chrome OS which still runs 32-bit userspace for the time being (long > story there). Watch out, your days are numbered! See [1]. > I won't repeat everything said in the individual patches since since > they are wordy enough as it is. > > Please enjoy and I hope this isn't too ugly/hacky for inclusion in > mainline. > > Thanks to Nick Desaulniers for his early review of these patches and > to Ricky for the super early prototype that some of this is based on. I can see that you've put a lot of effort into this, but I'm not thrilled with the prospect of maintaining these heuristics in the kernel. The callchain behaviour is directly visible to userspace, and all we'll be able to do is throw more heuristics at it if faced with any regression reports. Every assumption made about userspace behaviour results in diminishing returns where some set of programs no longer fall into the "supported" bucket and, on balance, I don't think the trade-off is worth it. If we were to do this in the kernel, then I'd like to see a spec for how frame-pointer based unwinding should work for Thumb and have it agreed upon and implemented by both GCC and LLVM. That way, we can implement the unwinder according to that spec and file bug reports against the compiler if it goes wrong. In lieu of that, I think we must defer to userspace to unwind using DWARF. Perf supports this via PERF_SAMPLE_STACK_USER and PERF_SAMPLE_REGS_USER, which allows libunwind to be used to create the callchain. You haven't mentioned that here, so I'd be interested to know why not. Finally, you've probably noticed that our unwinding code for compat tasks is basically identical to the code in arch/arm/. If the functionality is going to be extended, it should be done there first and then we will follow to be compatible. Cheers, Will [1] https://lore.kernel.org/lkml/20210602164719.31777-20-will@kernel.org/T/#u 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=-5.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 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 69BF0C47083 for ; Wed, 2 Jun 2021 17:57:40 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 3880C61DAA for ; Wed, 2 Jun 2021 17:57:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3880C61DAA 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=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc: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=5q0H0VPujeNPt4EmuR1BlVk3QzsTm+lUJ7hJU8j1h48=; b=SpHQTI/hff032v fsZFC5zrDZooU567t1Rqp2+HwW5M43dx9KDUvifsLIjY0lE6n5PpOt+hRYrhjqt+DfUUz5nhpAScU 5zR/G5NYAjh9Y8NtFLSnm21IYth/drKE9y1xt/Pyya80IXjpRKqpYxsVEJnQFrUuWesho6P/hm1RY WbrIGsLqYaqa+QwpkZzr+Ia3DLcXSKR2IOtUth6msmsKxxpDYgdl+L/fMvLVCpR+jSzGhRf4YH1Ct Db8+2Nk6Bm65edvZchuPRW7uSLvNTSdmxMGeP4DI9lIHDbmBkaWjZF1Q5FLJd5hsn4MsUcbnbO4KR wxyqIdsLmRgkCYXQ3dBA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1loV6A-005du3-7i; Wed, 02 Jun 2021 17:56:10 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1loV66-005dtH-Hi for linux-arm-kernel@lists.infradead.org; Wed, 02 Jun 2021 17:56:08 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 5793661DA5; Wed, 2 Jun 2021 17:56:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1622656566; bh=Czsuka7+HAGaSUNNQSSRfeXG6GJieqJ4DRUlmcntgAY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=t5cJqRiURMB0mvCDuGxAQqoQaubwsosndqXFSMS4MV01Blt3guNQdVa6KgxMskLh/ i+XoodFDYNHcDJfZPFwi2mG6UO2vAdFGvJuPRdFvR0WXkk5njxy4XZTyQMVyTVackS VF4gbeIEAs1034YIdmLym9QTFCge8bFpXghi1epxehKF01pD2JHU7BOgakp0zJ64PB iT0VSbSMOaUA7la2vkc96ulysSfE2XV2lGm9KCB8nzlSsrHQ45AMFOqxgBsUkl/pLN vyTpn801vbDdCAsWGnOUW/pHFTV3SV/xMl8bESrw5wcIrFTaT2xojOOvUSph92qO96 9uEKhbqRyHkdg== Date: Wed, 2 Jun 2021 18:55:59 +0100 From: Will Deacon To: Douglas Anderson Cc: Catalin Marinas , Nick Desaulniers , Seth LaForge , Ricky Liang , Alexander Shishkin , Arnaldo Carvalho de Melo , Ingo Molnar , Jiri Olsa , Mark Rutland , Namhyung Kim , Nathan Chancellor , Peter Zijlstra , clang-built-linux@googlegroups.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org Subject: Re: [PATCH 0/3] arm64: perf: Make compat tracing better Message-ID: <20210602175559.GC31957@willie-the-truck> References: <20210507205513.640780-1-dianders@chromium.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210507205513.640780-1-dianders@chromium.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210602_105606_613208_2EBA384F X-CRM114-Status: GOOD ( 24.97 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Hi Doug, Thanks for posting this, and sorry for the delay in getting to it. On Fri, May 07, 2021 at 01:55:10PM -0700, Douglas Anderson wrote: > The goal for this series is to improve "perf" behavior when 32-bit > userspace code is involved. This turns out to be fairly important for > Chrome OS which still runs 32-bit userspace for the time being (long > story there). Watch out, your days are numbered! See [1]. > I won't repeat everything said in the individual patches since since > they are wordy enough as it is. > > Please enjoy and I hope this isn't too ugly/hacky for inclusion in > mainline. > > Thanks to Nick Desaulniers for his early review of these patches and > to Ricky for the super early prototype that some of this is based on. I can see that you've put a lot of effort into this, but I'm not thrilled with the prospect of maintaining these heuristics in the kernel. The callchain behaviour is directly visible to userspace, and all we'll be able to do is throw more heuristics at it if faced with any regression reports. Every assumption made about userspace behaviour results in diminishing returns where some set of programs no longer fall into the "supported" bucket and, on balance, I don't think the trade-off is worth it. If we were to do this in the kernel, then I'd like to see a spec for how frame-pointer based unwinding should work for Thumb and have it agreed upon and implemented by both GCC and LLVM. That way, we can implement the unwinder according to that spec and file bug reports against the compiler if it goes wrong. In lieu of that, I think we must defer to userspace to unwind using DWARF. Perf supports this via PERF_SAMPLE_STACK_USER and PERF_SAMPLE_REGS_USER, which allows libunwind to be used to create the callchain. You haven't mentioned that here, so I'd be interested to know why not. Finally, you've probably noticed that our unwinding code for compat tasks is basically identical to the code in arch/arm/. If the functionality is going to be extended, it should be done there first and then we will follow to be compatible. Cheers, Will [1] https://lore.kernel.org/lkml/20210602164719.31777-20-will@kernel.org/T/#u _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel