Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp4094425iog; Tue, 28 Jun 2022 08:52:26 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vVg7z1vTaHsOaLokkFTH6C/+mh8a+kbObmDqi6MMsBbNjU0caUmuZvB6L9leJsD4kjubnL X-Received: by 2002:a17:90a:c782:b0:1ec:eea2:4236 with SMTP id gn2-20020a17090ac78200b001eceea24236mr314794pjb.20.1656431546413; Tue, 28 Jun 2022 08:52:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656431546; cv=none; d=google.com; s=arc-20160816; b=A6IkYz1QFLSjEFK2WVYSI4v9hjgG5LqbPNGaIFMNP7walHriJqj3dT7fBDo1SgleTj pslIQatpzarzqMZ8Ruv8JQOAKduTTpLc9LkNhghqIelwExEQ47P1Ach46ktQvqHX2vCs eMof0i+yuODg0ZzR3Px21CBbwKN9SNep6dLg6EsSTIjJOqyNlHuG3Dsa8ZUCwR2jQ6ME CUn3/rJtHoubv7dJ1Ra5iGjBsqiQGfZjkCzhYTnrAL4ATUKwrpp3sEnuAXG67GfqVZBF nz311J8mx4fstXM5AT2uZXo06/2ucERXwDPdoNT8zaNYZCP1yRGpSdbl8jicCSdTQ3/+ +1MA== 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=JcrXyHrbwCCKxz8IEipVzSt2camDv5QxjxkeQewO/T0=; b=dLqwLo6JK+WKRbE98dcU8Bh1WCgqhlPJlR7NGaFKktRqI7SejNfqU0krf759WAaqJs 9PNWEkwQabt1eN2KGFo491Q9w+maMy1adL49x4KLlToJQtANBu6hYJq+LLcgB6Y0CnBA LUgnoIzOANe8LFx3vI31+oOX2qmxgzIA1Ykrq8RtvSoKfhVdp7uhSrR7RKkO6xgKPmPN sCzb5xAtOATRHMXHlBu3ZW2o0bIqjfIoZwieNhxJ5lczqSJL7Zk0eMxTkPWtEQIiU7UZ y13Y7oAuiqIqR8XGzNgXGzRgajW4EKXdRGsPdBA7z7ctC5v2smPRwYicI5xPgzPyBE+r Sefw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=OwQ4ahQW; 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 y32-20020a056a00182000b0051bd440b069si22382022pfa.14.2022.06.28.08.52.11; Tue, 28 Jun 2022 08:52:26 -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=OwQ4ahQW; 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 S1347192AbiF1P16 (ORCPT + 99 others); Tue, 28 Jun 2022 11:27:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58682 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346637AbiF1P1z (ORCPT ); Tue, 28 Jun 2022 11:27:55 -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 CC9562DAAE for ; Tue, 28 Jun 2022 08:27:50 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id y32so22910341lfa.6 for ; Tue, 28 Jun 2022 08:27:50 -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=JcrXyHrbwCCKxz8IEipVzSt2camDv5QxjxkeQewO/T0=; b=OwQ4ahQWbrsPbES0ZStgp4gfOkrVfPAcdoH5+qPB9pW79khO5R7mCpTc3wOXx+zzsX 0zcdK55j/MaLvUaYAgls1Q3b+VYvR34VfQktWHj6RA84M7kWBdR0TAMldDPnZ9ItE4Xz YBUvPTRXYN4eO8GLWrf28lsaLT1tqrWT5e/XZg4T5GolUMherk27yEnBWxoorGAuXvGu pSWNPHlVS9f2YEE3m7F+Zu1g3XjKvHdyYLYk033NvwX0Slt3xjdVn+hxrBJicYwHfRBR iNaQAD6Cda/3fzyfZal8fs5HglZRCCHhZ2lsbjw0a56fBAUHaxRdjBYDoywsdYSxCIJX AcCA== 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=JcrXyHrbwCCKxz8IEipVzSt2camDv5QxjxkeQewO/T0=; b=ZpYFwp9VcS1zuItpUX7rzP8WXWyfIoZqWlXgKQnUFrm90A8n5dBqtdmfkIgQKVyKfG ThyGS/CDEdQeRrCtxe+7aRk5pFNVJ9marDdqppVY76qTgggWcQ5rrXcR7iIqK10rvrXY rYE524lQWvZRlbeFq0migjs0HEfkwynUGDJAap6VMFmkMKm6hdnvpciOnG7qXRYZq/n4 qp6lVALC5Q2wOxT35CqWp96Y3CKncEaFaw3AeMzZtDearn7pQ+U1U8uzy620UzDUxMi5 gwjK+dgNFlqA39jUsjvLOmg3oJPWc/rxFL3oJjaam/wLT44IxRHE98MgrH48IHJX5sXS UGSw== X-Gm-Message-State: AJIora/zPwFOczLMywrpJhn1IhtRIrmb701VX5OBWYp6bWa0pVJzizFR GOtPNtV9FsUn/XVCThGWiE7Cwp9SKVQps3NkzYRKYA== X-Received: by 2002:a05:6512:2520:b0:47f:8512:19c1 with SMTP id be32-20020a056512252000b0047f851219c1mr12110789lfb.540.1656430068858; Tue, 28 Jun 2022 08:27:48 -0700 (PDT) MIME-Version: 1.0 References: <20220628095833.2579903-1-elver@google.com> <20220628095833.2579903-4-elver@google.com> In-Reply-To: From: Dmitry Vyukov Date: Tue, 28 Jun 2022 17:27:37 +0200 Message-ID: Subject: Re: [PATCH v2 03/13] perf/hw_breakpoint: Optimize list of per-task breakpoints To: Marco Elver Cc: Peter Zijlstra , Frederic Weisbecker , Ingo Molnar , Thomas Gleixner , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Michael Ellerman , linuxppc-dev@lists.ozlabs.org, 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 Tue, 28 Jun 2022 at 16:54, Marco Elver wrote: > > > On a machine with 256 CPUs, running the recently added perf breakpoint > > > benchmark results in: > > > > > > | $> perf bench -r 30 breakpoint thread -b 4 -p 64 -t 64 > > > | # Running 'breakpoint/thread' benchmark: > > > | # Created/joined 30 threads with 4 breakpoints and 64 parallelism > > > | Total time: 236.418 [sec] > > > | > > > | 123134.794271 usecs/op > > > | 7880626.833333 usecs/op/cpu > > > > > > The benchmark tests inherited breakpoint perf events across many > > > threads. > > > > > > Looking at a perf profile, we can see that the majority of the time is > > > spent in various hw_breakpoint.c functions, which execute within the > > > 'nr_bp_mutex' critical sections which then results in contention on that > > > mutex as well: > > > > > > 37.27% [kernel] [k] osq_lock > > > 34.92% [kernel] [k] mutex_spin_on_owner > > > 12.15% [kernel] [k] toggle_bp_slot > > > 11.90% [kernel] [k] __reserve_bp_slot > > > > > > The culprit here is task_bp_pinned(), which has a runtime complexity of > > > O(#tasks) due to storing all task breakpoints in the same list and > > > iterating through that list looking for a matching task. Clearly, this > > > does not scale to thousands of tasks. > > > > > > Instead, make use of the "rhashtable" variant "rhltable" which stores > > > multiple items with the same key in a list. This results in average > > > runtime complexity of O(1) for task_bp_pinned(). > > > > > > With the optimization, the benchmark shows: > > > > > > | $> perf bench -r 30 breakpoint thread -b 4 -p 64 -t 64 > > > | # Running 'breakpoint/thread' benchmark: > > > | # Created/joined 30 threads with 4 breakpoints and 64 parallelism > > > | Total time: 0.208 [sec] > > > | > > > | 108.422396 usecs/op > > > | 6939.033333 usecs/op/cpu > > > > > > On this particular setup that's a speedup of ~1135x. > > > > > > While one option would be to make task_struct a breakpoint list node, > > > this would only further bloat task_struct for infrequently used data. > > > Furthermore, after all optimizations in this series, there's no evidence > > > it would result in better performance: later optimizations make the time > > > spent looking up entries in the hash table negligible (we'll reach the > > > theoretical ideal performance i.e. no constraints). > > > > > > Signed-off-by: Marco Elver > > > --- > > > v2: > > > * Commit message tweaks. > > > --- > > > include/linux/perf_event.h | 3 +- > > > kernel/events/hw_breakpoint.c | 56 ++++++++++++++++++++++------------- > > > 2 files changed, 37 insertions(+), 22 deletions(-) > > > > > > diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h > > > index 01231f1d976c..e27360436dc6 100644 > > > --- a/include/linux/perf_event.h > > > +++ b/include/linux/perf_event.h > > > @@ -36,6 +36,7 @@ struct perf_guest_info_callbacks { > > > }; > > > > > > #ifdef CONFIG_HAVE_HW_BREAKPOINT > > > +#include > > > #include > > > #endif > > > > > > @@ -178,7 +179,7 @@ struct hw_perf_event { > > > * creation and event initalization. > > > */ > > > struct arch_hw_breakpoint info; > > > - struct list_head bp_list; > > > + struct rhlist_head bp_list; > > > }; > > > #endif > > > struct { /* amd_iommu */ > > > diff --git a/kernel/events/hw_breakpoint.c b/kernel/events/hw_breakpoint.c > > > index 1b013968b395..add1b9c59631 100644 > > > --- a/kernel/events/hw_breakpoint.c > > > +++ b/kernel/events/hw_breakpoint.c > > > @@ -26,10 +26,10 @@ > > > #include > > > #include > > > #include > > > -#include > > > #include > > > #include > > > #include > > > +#include > > > #include > > > #include > > > > > > @@ -54,7 +54,13 @@ static struct bp_cpuinfo *get_bp_info(int cpu, enum bp_type_idx type) > > > } > > > > > > /* Keep track of the breakpoints attached to tasks */ > > > -static LIST_HEAD(bp_task_head); > > > +static struct rhltable task_bps_ht; > > > +static const struct rhashtable_params task_bps_ht_params = { > > > + .head_offset = offsetof(struct hw_perf_event, bp_list), > > > + .key_offset = offsetof(struct hw_perf_event, target), > > > + .key_len = sizeof_field(struct hw_perf_event, target), > > > + .automatic_shrinking = true, > > > +}; > > > > > > static int constraints_initialized; > > > > > > @@ -103,17 +109,23 @@ static unsigned int max_task_bp_pinned(int cpu, enum bp_type_idx type) > > > */ > > > static int task_bp_pinned(int cpu, struct perf_event *bp, enum bp_type_idx type) > > > { > > > - struct task_struct *tsk = bp->hw.target; > > > + struct rhlist_head *head, *pos; > > > struct perf_event *iter; > > > int count = 0; > > > > > > - list_for_each_entry(iter, &bp_task_head, hw.bp_list) { > > > - if (iter->hw.target == tsk && > > > - find_slot_idx(iter->attr.bp_type) == type && > > > + rcu_read_lock(); > > > + head = rhltable_lookup(&task_bps_ht, &bp->hw.target, task_bps_ht_params); > > > + if (!head) > > > + goto out; > > > + > > > + rhl_for_each_entry_rcu(iter, pos, head, hw.bp_list) { > > > + if (find_slot_idx(iter->attr.bp_type) == type && > > > (iter->cpu < 0 || cpu == iter->cpu)) > > > count += hw_breakpoint_weight(iter); > > > } > > > > > > +out: > > > + rcu_read_unlock(); > > > return count; > > > } > > > > > > @@ -186,7 +198,7 @@ static void toggle_bp_task_slot(struct perf_event *bp, int cpu, > > > /* > > > * Add/remove the given breakpoint in our constraint table > > > */ > > > -static void > > > +static int > > > toggle_bp_slot(struct perf_event *bp, bool enable, enum bp_type_idx type, > > > int weight) > > > { > > > @@ -199,7 +211,7 @@ toggle_bp_slot(struct perf_event *bp, bool enable, enum bp_type_idx type, > > > /* Pinned counter cpu profiling */ > > > if (!bp->hw.target) { > > > get_bp_info(bp->cpu, type)->cpu_pinned += weight; > > > - return; > > > + return 0; > > > } > > > > > > /* Pinned counter task profiling */ > > > @@ -207,9 +219,9 @@ toggle_bp_slot(struct perf_event *bp, bool enable, enum bp_type_idx type, > > > toggle_bp_task_slot(bp, cpu, type, weight); > > > > > > if (enable) > > > - list_add_tail(&bp->hw.bp_list, &bp_task_head); > > > + return rhltable_insert(&task_bps_ht, &bp->hw.bp_list, task_bps_ht_params); > > > else > > > - list_del(&bp->hw.bp_list); > > > + return rhltable_remove(&task_bps_ht, &bp->hw.bp_list, task_bps_ht_params); > > > } > > > > > > __weak int arch_reserve_bp_slot(struct perf_event *bp) > > > @@ -307,9 +319,7 @@ static int __reserve_bp_slot(struct perf_event *bp, u64 bp_type) > > > if (ret) > > > return ret; > > > > > > - toggle_bp_slot(bp, true, type, weight); > > > - > > > - return 0; > > > + return toggle_bp_slot(bp, true, type, weight); > > > } > > > > > > int reserve_bp_slot(struct perf_event *bp) > > > @@ -334,7 +344,7 @@ static void __release_bp_slot(struct perf_event *bp, u64 bp_type) > > > > > > type = find_slot_idx(bp_type); > > > weight = hw_breakpoint_weight(bp); > > > - toggle_bp_slot(bp, false, type, weight); > > > + WARN_ON(toggle_bp_slot(bp, false, type, weight)); > > > } > > > > > > void release_bp_slot(struct perf_event *bp) > > > @@ -678,7 +688,7 @@ static struct pmu perf_breakpoint = { > > > int __init init_hw_breakpoint(void) > > > { > > > int cpu, err_cpu; > > > - int i; > > > + int i, ret; > > > > > > for (i = 0; i < TYPE_MAX; i++) > > > nr_slots[i] = hw_breakpoint_slots(i); > > > @@ -689,18 +699,24 @@ int __init init_hw_breakpoint(void) > > > > > > info->tsk_pinned = kcalloc(nr_slots[i], sizeof(int), > > > GFP_KERNEL); > > > - if (!info->tsk_pinned) > > > - goto err_alloc; > > > + if (!info->tsk_pinned) { > > > + ret = -ENOMEM; > > > + goto err; > > > + } > > > } > > > } > > > > > > + ret = rhltable_init(&task_bps_ht, &task_bps_ht_params); > > > + if (ret) > > > + goto err; > > > + > > > constraints_initialized = 1; > > > > > > perf_pmu_register(&perf_breakpoint, "breakpoint", PERF_TYPE_BREAKPOINT); > > > > > > return register_die_notifier(&hw_breakpoint_exceptions_nb); > > > > It seems there is a latent bug here: > > if register_die_notifier() fails we also need to execute the err: label code. > > I think we should ignore it, because it's just a notifier when the > kernel dies. I'd rather have working breakpoints (which we have if we > made it to this point) when the kernel is live, and sacrifice some bad > behaviour when the kernel dies. I don't have a strong opinion either way. If ignoring such functions is acceptable practice, it sounds fine. > > Otherwise the patch looks good. > > > > Reviewed-by: Dmitry Vyukov > > Thanks, > -- Marco