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=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 47D5AC47082 for ; Mon, 7 Jun 2021 20:44:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 268E761108 for ; Mon, 7 Jun 2021 20:44:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230345AbhFGUpy (ORCPT ); Mon, 7 Jun 2021 16:45:54 -0400 Received: from mail-ot1-f41.google.com ([209.85.210.41]:37834 "EHLO mail-ot1-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230251AbhFGUpw (ORCPT ); Mon, 7 Jun 2021 16:45:52 -0400 Received: by mail-ot1-f41.google.com with SMTP id v19-20020a0568301413b0290304f00e3d88so18098105otp.4 for ; Mon, 07 Jun 2021 13:44:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZMWLwrT3tzkNROjejSZHkSJGqtLsxOXJijLmp+N+WUA=; b=UAeMsV9yT+XI9c0oZrU2PdwjsPV8qukzfoBfkKTnSO101uHR1/4EyiiyPkXZtUErQM 3rWNQux76ijI9+CBDFUEfG5VMI0VnM5IxE3ZwutiGpuhujp4iZHBHDd4LKpU3jDi/VFo UEpjKLKfNzzk0hew56IaTQl3XJwkffgoMu1+M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZMWLwrT3tzkNROjejSZHkSJGqtLsxOXJijLmp+N+WUA=; b=BDG3o1CGWlypANHJEw56QvOXe4gwd3xyG+hcjyR58aYmv21RJrcuzuHzlNse5JnQb0 tc+TWoaes1zIGeoHtt7Ff0mESo5//3EmSpIY49ULBmhWncnShOTduIzNSgonPtwbrSkA DqmIqvndHNH/fEWR3R/JBirrCxM/OcNXMNzPaoZfHxuO5J3EMKe5Fx7iI/y0PT7Cadb6 TmKUCAOXTzRAWRZB+VtDDOudOAJGyzKhED6t+EbFgRQQGv5T4t+15S3sDhUcPD4kUC4U FQ0+zjBy4EV+orZS7HtzUdNw17w1GYDtwhm0gvr7kQCDWkC0Yfu+2alWJiy6u8q0EDyO jq7A== X-Gm-Message-State: AOAM533bk9WnA9M+z5rRgogzJVV0FX+v6da0vr/sZvw7Q0wM+rMlk02H g9U+5uJNw+38YoLInR7H+iFY0jIzIg2+LA== X-Google-Smtp-Source: ABdhPJxECDutEJJ5ecwEfhV8fL+0P4/o9jx8M+8f0OW9JGx1PCdfXUXc+SMcGOP2a68HHOxIVzgrlw== X-Received: by 2002:a9d:206:: with SMTP id 6mr16093969otb.31.1623098579708; Mon, 07 Jun 2021 13:42:59 -0700 (PDT) Received: from mail-oo1-f46.google.com (mail-oo1-f46.google.com. [209.85.161.46]) by smtp.gmail.com with ESMTPSA id k8sm168237ool.5.2021.06.07.13.42.59 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Jun 2021 13:42:59 -0700 (PDT) Received: by mail-oo1-f46.google.com with SMTP id k10-20020a4abd8a0000b0290249ed2f2919so719481oop.4 for ; Mon, 07 Jun 2021 13:42:59 -0700 (PDT) X-Received: by 2002:a5b:54a:: with SMTP id r10mr26455324ybp.476.1623098107901; Mon, 07 Jun 2021 13:35:07 -0700 (PDT) MIME-Version: 1.0 References: <20210507205513.640780-1-dianders@chromium.org> <20210602175559.GC31957@willie-the-truck> In-Reply-To: <20210602175559.GC31957@willie-the-truck> From: Doug Anderson Date: Mon, 7 Jun 2021 13:34:56 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 0/3] arm64: perf: Make compat tracing better To: Will Deacon 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 , Linux ARM , LKML , linux-perf-users@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Wed, Jun 2, 2021 at 10:56 AM Will Deacon wrote: > > 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]. Yeah, folks on the Chrome OS team are aware and we're trying our darndest to move away. It's been an unfortunate set of circumstances that has kept us on 32-bit this long. :( BTW: I like your suggestion of "retirement" as a solution to dealing with this problem, but I'm not quite ready to retire yet. > > 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. Given how long this has been going on, I'd somewhat guess that getting this implemented in GCC and LLVM is 1+ year out. Presumably Chrome OS will be transitioned off 32-bit ARM by then. > 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. Good point. So I guess I didn't mention it because: a) I really know very little about perf. I got roped in this because I understand stack unwinding, not because I know how to use perf well. :-P So I personally have no idea how to set this up. b) In the little bit of reading I did about this, people seemed to say that using libunwind for perf sampling was just too slow / too much overhead. > 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. That's fair. I doubt that submitting patches to this area of code for arm32 would be enjoyable, so I'll pass if it's all the same. Given your feedback, I think it's fair to consider ${SUBJECT} patch abandoned then. I'll see if people want to land it as a private patch in the Chrome OS tree for the time being until we can more fully abandon arm32 support or until the ARM teams working on gcc and clang come up with a standard that we can support more properly. In the meantime, if anyone cares to pick this patch up and move forward, feel free to do so with my blessing. -Doug 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=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 7A1B5C47094 for ; Mon, 7 Jun 2021 20:36:56 +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 3514260200 for ; Mon, 7 Jun 2021 20:36:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3514260200 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=TvyCtXXBSA5QeXWeGTeejnU2HbAb6VTHazRafdpXYfs=; b=RWhTDD//SeeN0u IagSHjnaKMbEjUIBfLfx3wxJy7KMwoKxvBXRQidgZImBWw5uiRbulnpeO6BCoq1m1S7VBvySF27zF sTyUQs/pmFyGqMd5G2eKbTdkk4FwxPtMP833StzNvokBDcSKnohLJ5Yn9EbArUIl2jJhX2WDaxD3D tts4l5GN5BtZ5Z8oMrrwTwhWmyi9ukzZWQEK+zNOnGdJNQmTzQuuXPETiVKdOwUMBp9cnK1tGuI1v JLRYl+LWJ8p5Wjo+p5UDGTIUH+Cm/p3zHaPEV3OGQV4vKm/2k2j94T/77329WbGpz2qYeAK4aEPJf akYJ/G9ZaU0ssxX0nOXQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lqLxs-005LmT-QH; Mon, 07 Jun 2021 20:35:16 +0000 Received: from mail-qk1-x72a.google.com ([2607:f8b0:4864:20::72a]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lqLxp-005Lm8-0J for linux-arm-kernel@lists.infradead.org; Mon, 07 Jun 2021 20:35:14 +0000 Received: by mail-qk1-x72a.google.com with SMTP id j184so18068936qkd.6 for ; Mon, 07 Jun 2021 13:35:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZMWLwrT3tzkNROjejSZHkSJGqtLsxOXJijLmp+N+WUA=; b=UAeMsV9yT+XI9c0oZrU2PdwjsPV8qukzfoBfkKTnSO101uHR1/4EyiiyPkXZtUErQM 3rWNQux76ijI9+CBDFUEfG5VMI0VnM5IxE3ZwutiGpuhujp4iZHBHDd4LKpU3jDi/VFo UEpjKLKfNzzk0hew56IaTQl3XJwkffgoMu1+M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZMWLwrT3tzkNROjejSZHkSJGqtLsxOXJijLmp+N+WUA=; b=uGXOOvBzyIw+Ge611m4NBsGat7rztrs4uuFDtPoE7Phah2NyMUj5F/VoF6dksom5p3 vHE2dQbTTxCI0ytyDqAsURHYZcEtRFT490D1F8ch6KR3+8iVU34/e9c15At9RnOUFl90 qCyanblIWw7K6Jb4BlttBUnV0msQz4jIC3zEOlbSMUKypN1M0B10ZeMGjtUF7XKnQJWs Uu0jQjQdEyKle/9zSi3gS9/x+DUv8QTbGaEpBZ9iUXBOOd6tM7s8AW1wEUrSS69odT+A BAH/Yv60avlrIs3nAZnm4XBXJ80bYxyIqjRxXHqrSP4eY5cdAYriKF7ni0bWOh4vG0r8 Lo+g== X-Gm-Message-State: AOAM533rl1TEZFcZfE7Wr8qPAO3uveqGopd6voPgvwF/MTjCNlC1zq+S Va/Q0gxnsij88LW0GVTqkpS1aOPbfpwCcQ== X-Google-Smtp-Source: ABdhPJxAEV8CapWwdxvKSAko7Blf5SDGom1lbb1qSeSN3NfVqd+oO8IIIApcznaNQkgA7Cjc00vebA== X-Received: by 2002:ae9:c010:: with SMTP id u16mr18380905qkk.133.1623098109823; Mon, 07 Jun 2021 13:35:09 -0700 (PDT) Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com. [209.85.219.172]) by smtp.gmail.com with ESMTPSA id d10sm4330818qtd.82.2021.06.07.13.35.08 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Jun 2021 13:35:09 -0700 (PDT) Received: by mail-yb1-f172.google.com with SMTP id i6so12275360ybm.1 for ; Mon, 07 Jun 2021 13:35:08 -0700 (PDT) X-Received: by 2002:a5b:54a:: with SMTP id r10mr26455324ybp.476.1623098107901; Mon, 07 Jun 2021 13:35:07 -0700 (PDT) MIME-Version: 1.0 References: <20210507205513.640780-1-dianders@chromium.org> <20210602175559.GC31957@willie-the-truck> In-Reply-To: <20210602175559.GC31957@willie-the-truck> From: Doug Anderson Date: Mon, 7 Jun 2021 13:34:56 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 0/3] arm64: perf: Make compat tracing better To: Will Deacon 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 , Linux ARM , LKML , linux-perf-users@vger.kernel.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210607_133513_093367_7A32C658 X-CRM114-Status: GOOD ( 43.07 ) 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, On Wed, Jun 2, 2021 at 10:56 AM Will Deacon wrote: > > 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]. Yeah, folks on the Chrome OS team are aware and we're trying our darndest to move away. It's been an unfortunate set of circumstances that has kept us on 32-bit this long. :( BTW: I like your suggestion of "retirement" as a solution to dealing with this problem, but I'm not quite ready to retire yet. > > 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. Given how long this has been going on, I'd somewhat guess that getting this implemented in GCC and LLVM is 1+ year out. Presumably Chrome OS will be transitioned off 32-bit ARM by then. > 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. Good point. So I guess I didn't mention it because: a) I really know very little about perf. I got roped in this because I understand stack unwinding, not because I know how to use perf well. :-P So I personally have no idea how to set this up. b) In the little bit of reading I did about this, people seemed to say that using libunwind for perf sampling was just too slow / too much overhead. > 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. That's fair. I doubt that submitting patches to this area of code for arm32 would be enjoyable, so I'll pass if it's all the same. Given your feedback, I think it's fair to consider ${SUBJECT} patch abandoned then. I'll see if people want to land it as a private patch in the Chrome OS tree for the time being until we can more fully abandon arm32 support or until the ARM teams working on gcc and clang come up with a standard that we can support more properly. In the meantime, if anyone cares to pick this patch up and move forward, feel free to do so with my blessing. -Doug _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel