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=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 ED3F1C48BE6 for ; Mon, 14 Jun 2021 16:03:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BAB8261245 for ; Mon, 14 Jun 2021 16:03:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234071AbhFNQFS (ORCPT ); Mon, 14 Jun 2021 12:05:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48942 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233583AbhFNQFR (ORCPT ); Mon, 14 Jun 2021 12:05:17 -0400 Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3B4DFC061767 for ; Mon, 14 Jun 2021 09:03:14 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id f30so21993156lfj.1 for ; Mon, 14 Jun 2021 09:03:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3MqGDvp9ypUCvhlLUOO4ezsTJgglqtbS6x/EUZzU8+Q=; b=Fy7Y+DeoKvsZICPPwA01TqMBiH2RFRKDNCaiYWD2UTBYSxZ4pdeg1d/ChfVV734TmQ DT17igrzvRDC6rSUoqpPatzrJNeyqYGImyCufJH3ofLDeNrnxly9mav9aZJLyg1UVkoB 1qO7A8Pp7Sw0Yt1+gn+KVxTl9wtq5gPrdjAgo7p8Dw6cP35cf73qe5IC2SZlU4EN6JST e57ab6dbcs/ksdm+WbwRkuTpfFsQSuzRLgI1XcClxOzoNJYFUWWYmvcoi9U0nWAQ/FND HDaz4KI7R9lqXlsABdzH8orcCS5kRcK7Gl62H7bYrC+WblskggwIu+lBaRzzUoj/M9As nNVw== 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=3MqGDvp9ypUCvhlLUOO4ezsTJgglqtbS6x/EUZzU8+Q=; b=FddlVVpSTJE9kQWaminH9FYccDvlLCESoUyCEWDiCIv9I8xh7W1Knh3DzSLm8h0DC9 5BTvVNXUvIE8pkGW7trgRlQHlHhWNyqJGPLdflPoGDMpwz4/xDhSANVM2NpOYU5zsMPf MLAATZPhvItSJ75oNizXqrx2fT+sMVClbHr3nBaMohZCwxhg7Y8D4WKA7afa4uUntDK5 A1F9NpOTULa29c+V+mLuUeWqkR1wxg/DuOYRv7o4mmIXHKaRYgMAKGEbtjpZfY2Ips/h SRnkAyzFRD4h9FwtMcQZeSW/KyoED4+48G2D0HdyoANwRcyZ+RfRG8REOJcl+Ej2tfhT qBvA== X-Gm-Message-State: AOAM532XEQxsW04NPVC27kcjKOfYbkNrTK7CMvO3DSddf4AwWE1ynLqJ Y1enVEgCuB5GP9PwYbNiN0YyyYAPuZZDZC3eDAg14g== X-Google-Smtp-Source: ABdhPJy9T1fv6ss2YqKm05JzBWeSmxI3e8pir4dr37jITMTf4Csn9UJP+HwVMcgnlLH3mP9Ymy3BeWib7d8pn9zu3KY= X-Received: by 2002:ac2:5cd6:: with SMTP id f22mr13208808lfq.73.1623686592188; Mon, 14 Jun 2021 09:03:12 -0700 (PDT) MIME-Version: 1.0 References: <20210612202505.GG68208@worktop.programming.kicks-ass.net> <202106140817.F584D2F@keescook> <20210614154639.GB68749@worktop.programming.kicks-ass.net> In-Reply-To: <20210614154639.GB68749@worktop.programming.kicks-ass.net> From: Nick Desaulniers Date: Mon, 14 Jun 2021 09:03:00 -0700 Message-ID: Subject: Re: [PATCH v9] pgo: add clang's Profile Guided Optimization infrastructure To: Peter Zijlstra Cc: Kees Cook , Marco Elver , Bill Wendling , Jonathan Corbet , Masahiro Yamada , Linux Doc Mailing List , LKML , Linux Kbuild mailing list , clang-built-linux , Andrew Morton , Nathan Chancellor , Sami Tolvanen , Fangrui Song , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , Andrey Konovalov , Dmitry Vyukov , Johannes Berg , oberpar@linux.vnet.ibm.com, linux-toolchains@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Mon, Jun 14, 2021 at 8:46 AM Peter Zijlstra wrote: > > On Mon, Jun 14, 2021 at 08:26:01AM -0700, Kees Cook wrote: > > > 2. Like (1) but also keep GCOV, given proper support for attribute > > > no_instrument_function would probably fix it (?). > > > > > > 3. Keep GCOV (and KCOV of course). Somehow extract PGO profiles from KCOV. > > > > > > 4. Somehow extract PGO profiles from GCOV, or modify kernel/gcov to do so. > > > > If there *is* a way to "combine" these, I don't think it makes sense > > to do it now. PGO has users (and is expanding[1]), and trying to > > optimize the design before even landing the first version seems like a > > needless obstruction, and to likely not address currently undiscovered > > requirements. > > Even if that were so (and I'm not yet convinced), the current proposal > is wedded to llvm-pgo, there is no way gcc-pgo could reuse any of this > code afaict, which then means they have to create yet another variant. Similar to GCOV, the runtime support for exporting such data is heavily compiler (and compiler version) specific, as is the data format for compilers to consume. We were able to reuse most of the runtime code between GCC and Clang support in GCOV; I don't see why we couldn't do a similar factoring of the runtime code being added to the kernel here, should anyone care to pursue implementing PGO with GCC. Having an implementation is a great starting point for folks looking to extend support or to understand how to support PGO in such a bare metal environment (one that doesn't dynamically link against traditional compiler runtimes). -- Thanks, ~Nick Desaulniers