Received: by 2002:a5d:925a:0:0:0:0:0 with SMTP id e26csp360396iol; Thu, 9 Jun 2022 05:27:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJws+a5HIrWNekBvvD9Vt8rdHez3fidRouKXMaKEZ8GMmPNX0YTcRatheogloKZm5uocyjXt X-Received: by 2002:a17:907:7290:b0:6ff:1fa2:e9e3 with SMTP id dt16-20020a170907729000b006ff1fa2e9e3mr35462263ejc.345.1654777667898; Thu, 09 Jun 2022 05:27:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654777667; cv=none; d=google.com; s=arc-20160816; b=EdLRXpZhIWUQZm1gnjVG/2A6mpeHUD81FWrU7sNqa0qi8sGUcDMjbaM2FGkRcKrKzj G5MCOQ3Z1i11+fHXApKndWYryuxijNRSqCWhR2tVWvz/oGmWFgkm0STYPi6hjefscbh9 yFvyXWuRuJXJEPgxvszwacrg2PbP9WCbw/esER6WA34qO+k4O/vkZoncOyN1A1W3ZnnX alNsZ2awr/cwO+uGZcEvo/F0GLwbywFHdH5Gjhjyip4NK26k6svXGweH84eCwNJtbr6Z 0HgViqbA6L4QHAkwV25HWbsuBecHJE0VNS9OJB5oDfXizfWbSVuUyfyoO7HFNvffE3ZQ /vQw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=F1uvmSUGsFaK9iCgbfPZK7tHgGjdwwOqEzHuFfRRs9g=; b=0b2VNQmT083eHYEeuB8siPO2wc9PFXn3bOSE+bshk0a+017M0whWHCf/QNGgfhzlKx wHg5GrJG04nQU0gylS0CJaggzrb5V/4G6oLKK3SfJ7c1+Dx/b0IhuJzZo207xVuj2iNU g9LWYFFDUC5HkovR9+YRMg2c7zAniXXmZRIr0EIGvUXEyXH5k8t2u4tZcJ4Dfo1oP5dS KyTS069UXwLp5uOEbTs7to0ezSZD1HTmFOkX3LMZiy38D2Lw0dOum0V6sv4Kxsjs7vAY vosV4vfV+wR0zf5bf6TF6r8TA70vjn5ydHP0A26t6ndVbm7wVcdMaXaZXF53PMdscIDl m5MA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=WUkfehuO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qk20-20020a1709077f9400b00710dabed66bsi18262167ejc.601.2022.06.09.05.27.22; Thu, 09 Jun 2022 05:27:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=WUkfehuO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238412AbiFIMD3 (ORCPT + 99 others); Thu, 9 Jun 2022 08:03:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35664 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245022AbiFIMD1 (ORCPT ); Thu, 9 Jun 2022 08:03:27 -0400 Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E346F6CABC for ; Thu, 9 Jun 2022 05:03:25 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id y29so25893232ljd.7 for ; Thu, 09 Jun 2022 05:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=F1uvmSUGsFaK9iCgbfPZK7tHgGjdwwOqEzHuFfRRs9g=; b=WUkfehuOGVt1LjXm/E8vM1d53pS7ZaW2P1Do4rYDPDj9x3HcIScUEYL429OjpkXLee jKnWe2xHFGpQfUYwz4KCSM/QSRqVXpKdCN5oz8GsDU5DuvHD+3t72nhyjn/C42AH+FJE B8u60LeDgw6TrkfqcF9cmWwgXAWc4dsk/+kvEweY3EkZrpr+48Ul3ihaLREa0VHJVfGd QF/a5FQ4uroEtUMkhyWKOGgGpuB3aSGc2gGY+rP76oDwg8gFOBmuE+hJov/QxpNKWfMM H/bSpILdyre2NJj4nJFgAVNIzQ30RuGAce6bZLMEB3lWofAjSWjRfethyraCxfQtJqJ5 +zTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=F1uvmSUGsFaK9iCgbfPZK7tHgGjdwwOqEzHuFfRRs9g=; b=Z1iL4boVF2kd0B1mbLRkV+G18NLTBwLH5smVQxSkZXRqF9g8uc7dvyU5o8fw2oicLt EfP1m8gKI6Dr6asprVaetzBfIoNQSJ8Z38pQY/1Zd0EjfjQuiliJq1BnCYlytlDbG4RV 6W4LXUo56eSAxWexoK8gbPYL/Q2gpIh+apGHs96PGUE96C4SfBmO/OFdv0wMOYra0ZSS nCdAvYhRV9hb2tzEKdrq9GLZFbqGsSN5uflpqqlCSGEvAQKU3TrMPzpFK/SpYMSo4Pl8 bKq9qne/DyIQs9uvvsujfOpA3i8LH8GOsVMbk0qglGYCHkVorh7b6cluHJQLFdABuySK XfiQ== X-Gm-Message-State: AOAM5306H+4TpgzEaUDF2GQsWzT3Ti8y+ArW8brOi78l1kvSDsWJnXTB HIdcxoW71q6B9YKSSfOewzl3XDonvJPW0corAmtLrw== X-Received: by 2002:a2e:b0fc:0:b0:255:6f92:f9d4 with SMTP id h28-20020a2eb0fc000000b002556f92f9d4mr21901545ljl.92.1654776203624; Thu, 09 Jun 2022 05:03:23 -0700 (PDT) MIME-Version: 1.0 References: <20220609113046.780504-1-elver@google.com> <20220609113046.780504-5-elver@google.com> In-Reply-To: <20220609113046.780504-5-elver@google.com> From: Dmitry Vyukov Date: Thu, 9 Jun 2022 14:03:12 +0200 Message-ID: Subject: Re: [PATCH 4/8] perf/hw_breakpoint: Make hw_breakpoint_weight() inlinable To: Marco Elver Cc: Peter Zijlstra , Frederic Weisbecker , Ingo Molnar , Thomas Gleixner , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , linux-perf-users@vger.kernel.org, x86@kernel.org, linux-sh@vger.kernel.org, kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 9 Jun 2022 at 13:31, Marco Elver wrote: > > Due to being a __weak function, hw_breakpoint_weight() will cause the > compiler to always emit a call to it. This generates unnecessarily bad > code (register spills etc.) for no good reason; in fact it appears in > profiles of `perf bench -r 100 breakpoint thread -b 4 -p 128 -t 512`: > > ... > 0.70% [kernel] [k] hw_breakpoint_weight > ... > > While a small percentage, no architecture defines its own > hw_breakpoint_weight() nor are there users outside hw_breakpoint.c, > which makes the fact it is currently __weak a poor choice. > > Change hw_breakpoint_weight()'s definition to follow a similar protocol > to hw_breakpoint_slots(), such that if defines > hw_breakpoint_weight(), we'll use it instead. > > The result is that it is inlined and no longer shows up in profiles. > > Signed-off-by: Marco Elver > --- > include/linux/hw_breakpoint.h | 1 - > kernel/events/hw_breakpoint.c | 4 +++- > 2 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/include/linux/hw_breakpoint.h b/include/linux/hw_breakpoint.h > index 78dd7035d1e5..9fa3547acd87 100644 > --- a/include/linux/hw_breakpoint.h > +++ b/include/linux/hw_breakpoint.h > @@ -79,7 +79,6 @@ extern int dbg_reserve_bp_slot(struct perf_event *bp); > extern int dbg_release_bp_slot(struct perf_event *bp); > extern int reserve_bp_slot(struct perf_event *bp); > extern void release_bp_slot(struct perf_event *bp); > -int hw_breakpoint_weight(struct perf_event *bp); > int arch_reserve_bp_slot(struct perf_event *bp); > void arch_release_bp_slot(struct perf_event *bp); > void arch_unregister_hw_breakpoint(struct perf_event *bp); > diff --git a/kernel/events/hw_breakpoint.c b/kernel/events/hw_breakpoint.c > index 8e939723f27d..5f40c8dfa042 100644 > --- a/kernel/events/hw_breakpoint.c > +++ b/kernel/events/hw_breakpoint.c > @@ -125,10 +125,12 @@ static __init int init_breakpoint_slots(void) > } > #endif > > -__weak int hw_breakpoint_weight(struct perf_event *bp) Humm... this was added in 2010 and never actually used to return anything other than 1 since then (?). Looks like over-design. Maybe we drop "#ifndef" and add a comment instead? > +#ifndef hw_breakpoint_weight > +static inline int hw_breakpoint_weight(struct perf_event *bp) > { > return 1; > } > +#endif > > static inline enum bp_type_idx find_slot_idx(u64 bp_type) > { > -- > 2.36.1.255.ge46751e96f-goog >