Received: by 2002:a5d:925a:0:0:0:0:0 with SMTP id e26csp431975iol; Thu, 9 Jun 2022 06:46:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzlmV7VBqwEMZe1LP+H5z3RSw5i51ruIgLZxU+5Km3YvfL+u6sqKMtXTKNEaBIqChJSkwK8 X-Received: by 2002:a17:90b:4b51:b0:1e8:71cb:4d18 with SMTP id mi17-20020a17090b4b5100b001e871cb4d18mr3661524pjb.108.1654782371570; Thu, 09 Jun 2022 06:46:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654782371; cv=none; d=google.com; s=arc-20160816; b=AD8IwdMmWB+/1iP8/2fxjKmwOtvKMTzYYrSEAYQkcfTLbbAGyCF3vp+X3pBMq0KxOZ F6IfCaCs0b/uTJ4cK+mj+RMuSUuZACB5CtAnZXrnwbTzgDjJKjLdftEME43HsLo9zgjt bj+qusathTrvyZYTtuXjdmkhgj5b8E4EFzwf0tb4/VPeNGJYGRpZfhoNGOKkujgemVA6 T0brgIsfuNaODxw1mWqZunI8Kwd7FF0y01KbcWrCExnYfJNMUrC9pH6MA+V8nBFry/l0 hjmKF0Z8gEUjZ3CvRjYhEvNUtmTR6QhE5ti9X76IDHbVEhwYZNcrl1O1KfyweWjsetwS N2zw== 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=xOQI9nYJjsWx7RUNIP4XR5dRmZHTAqrUHXmWvjF6nBY=; b=S5ahLRZVkG5LU406SSm8ac7A8mDh9IrCyqJGYtzDTQmeXMsq3bizT8ZGDqFL284KO9 kB/0h4tmwQ5MlO8qtP6ql00VIQub/wxq8F4hJc1i2lYJqZ03SViiD5yWx7Sr1he8RAyd GAdiZQgxed2Y0pKnDfP3r2dZQ5Nlb4npKr/gNeJXBIQ8/Xsay1m6usMi0dY/rtb1SumK QOTih/QvrYeRwY4WHGovFoBXz2iPsvgwfN+UnlWZCIJ9P/Kw3u2oNMunzhYPXjajzDLL 7KBEXQ0YBTHtiw2bXCDp23cpkY3Src20+XwU5/+j5mymMTt3Y/5jbkXRT+gO6EbngS5x rYuw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=X7FFvILg; 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 l16-20020a170902f69000b00161888ee6fesi37893237plg.474.2022.06.09.06.45.55; Thu, 09 Jun 2022 06:46:11 -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=X7FFvILg; 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 S238980AbiFINF5 (ORCPT + 99 others); Thu, 9 Jun 2022 09:05:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51876 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233736AbiFINFz (ORCPT ); Thu, 9 Jun 2022 09:05:55 -0400 Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1CA2EFD3 for ; Thu, 9 Jun 2022 06:05:54 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id h23so37893783lfe.4 for ; Thu, 09 Jun 2022 06:05:54 -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=xOQI9nYJjsWx7RUNIP4XR5dRmZHTAqrUHXmWvjF6nBY=; b=X7FFvILgfoQbhrO16Zdxh9SVLvxEy8XxHsClf1zUJteoAVjCcWwi/RF6y3u4H8+0Za DHpnXD3XLZWCkSwQbpXBQuWjcZs+yIeVMe/o8FcP4I4JeO5gvOU627r0k+g9afDZ6ix/ 1OxHn/GxfQ5hBL1SVgRI/msxQdAL2zBCOWjMRgPzbk2JC+M8drt0uevaSbVbi8y1jM2g DLcEKYb2VV4E95XAjOqt8+Sed/XY6Ou2af/ft2KCmmolakWr/jMd0CE4Z/9vm4z2B59u FW7KmqiYXblPyAIdl+FYoOBANpgcqMqQw7CzXhxATrZLUL0VrGGWg8vcNA+fFnoLlJ9M H42w== 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=xOQI9nYJjsWx7RUNIP4XR5dRmZHTAqrUHXmWvjF6nBY=; b=YMGlLnNws94gUGHdolzI3kBkfgpVQGJXLzsntLPV25jFsCXvHOMiu2ndzanPi4G6cw /e1xIUQBaj+OaM8GZBy0OsM1XRi1nSrb6frpDg1Dg/4trfvwCmtXF6lOgf3MPIHLrLO1 FlhCvYPlpxQr0ESyfAuPy8P7fHp/b8aNTe2MFnYt7+/VKapXYh2OfOLsIVIuTiXmqTH6 km08JbKcDL12SOU2kz1leF+wEm+0Ogx6KEeTesnVQeEn8nZA3JeF57lYScKBWAdzc9Bh zKqcCVbpK5I0JVKygpDIiS5Vu+X+004qKy/O7AmwWoK9If2HAQNaOym/ao0QctuKCs2w 9fug== X-Gm-Message-State: AOAM531T6al8+XbCaP6CUjeT65a7e69ZFolyuNCll8uARnoeRPZRQLMl dlOeoQXZDf+mfDihoRqWLPVr6YfL5L9MvBbuOOtsdw== X-Received: by 2002:ac2:4f11:0:b0:479:3554:79d with SMTP id k17-20020ac24f11000000b004793554079dmr15389711lfr.417.1654779952199; Thu, 09 Jun 2022 06:05:52 -0700 (PDT) MIME-Version: 1.0 References: <20220609113046.780504-1-elver@google.com> <20220609113046.780504-2-elver@google.com> In-Reply-To: From: Dmitry Vyukov Date: Thu, 9 Jun 2022 15:05:40 +0200 Message-ID: Subject: Re: [PATCH 1/8] 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 , 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 14:53, Marco Elver wrote: > > On Thu, Jun 09, 2022 at 02:30PM +0200, Dmitry Vyukov wrote: > [...] > > > + rcu_read_lock(); > > > > Why do we need rcu_read_lock() here? > > The patch does not change anything with respect to locking, so all > > accesses to the container should still be protected by nr_bp_mutex. > > Similarly for the rcu variant of for_each below. > [...] > > > + 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) { > > It's part of rhashtable's interface requirements: > > /** > * rhltable_lookup - search hash list table > * @hlt: hash table > * @key: the pointer to the key > * @params: hash table parameters > * > * Computes the hash value for the key and traverses the bucket chain looking > * for a entry with an identical key. All matching entries are returned > * in a list. > * > * This must only be called under the RCU read lock. > * > * Returns the list of entries that match the given key. > */ > > Beyond that, even though there might not appear to be any concurrent > rhashtable modifications, it'll be allowed in patch 6/8. Furthermore, > rhashtable actually does concurrent background compactions since I > selected 'automatic_shrinking = true' (so we don't leak tons of memory > after starting and killing those 1000s of tasks) -- there's this > call_rcu() in lib/rhashtable.c that looks like that's when it's used. > This work is done in a deferred work by rht_deferred_worker(). I see. Thanks. Reviewed-by: Dmitry Vyukov