Received: by 2002:a05:6358:489b:b0:bb:da1:e618 with SMTP id x27csp148688rwn; Fri, 16 Sep 2022 17:16:29 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4yFI0d8jsaKzfV9CuehTAMiH4LUWR/THeIr2SwrpZCI+QwlmFYnqYBC/8kqJDabT7nxp/n X-Received: by 2002:a63:1a04:0:b0:42b:d33a:2613 with SMTP id a4-20020a631a04000000b0042bd33a2613mr6493982pga.429.1663373788826; Fri, 16 Sep 2022 17:16:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1663373788; cv=none; d=google.com; s=arc-20160816; b=vTLgvPzuvy4dIZ/Llc4DLklLsBhsrOY0VnTRlkyfWlLIlK4DYJPyjvhRYvJ4aH2vc0 E3pxGrBOqKzeLFFjy+GoLzVzPl3o3rASK4v1o9YoWR9tIB6OxvT7VKa29G18ML93HEtu O1wIQ86nSyqgGbotVt7jH8jI/tCA+pGOUDwaoDnw+Va65qW/4t+IgbYtBCfkOaSdNK3K zF+T8zDvGSg/AC7q0wZkeOzMSXj+j08lKFVDj1G19T922vgHf+DWbWDIebtD/+S0fsKd /iVr/FwXEgkGReyMIya/8CZ6R1g2+HBI61TYlFK7t6jFBLAfl4ob0P/F5Yc9NOuQo9qV Q/aQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=Tk2u/s6sRgGMLRQAuOfvmpgu8lIuCMGaWAOQeLrHHow=; b=vACs40ll4IMdao2d9n2aBQgVJK6BsHaApQ54vSafHOoxqSD5p6w8Cnix+Jvsxoa3eB QxFsYquxJN8O2vinUS5yzARhvBZJLvT7cmx6y0GWJcHJy7xHsXbV/Lck+znWWjEJbcYK oqqZsgGykXVmLjs3nBV1O/kSBVhAIPCx65TNTU8PiJum4Gx40lhPsxu75BVymjAZa3cP aj+9Hk3Lyc/VYtZT7iVXfbChXML12lTXbLyuz2fbeAgJ3bA3GgI1MgCzfO66ZgcUkzoB VYANUZ7JMvbbRHAnPn5VW3FeWFHYvmYFMI8TtSFK12vtZx+FjgxQfpeDmvsEl9kwOqas 66Lw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b=x4KMUEi6; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j5-20020a170902da8500b0016cb5071ee5si24487197plx.332.2022.09.16.17.16.04; Fri, 16 Sep 2022 17:16:28 -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=@joelfernandes.org header.s=google header.b=x4KMUEi6; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229613AbiIPWTT (ORCPT + 99 others); Fri, 16 Sep 2022 18:19:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52700 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229462AbiIPWTR (ORCPT ); Fri, 16 Sep 2022 18:19:17 -0400 Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 21BB3B82 for ; Fri, 16 Sep 2022 15:19:16 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id h21so17026202qta.3 for ; Fri, 16 Sep 2022 15:19:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=Tk2u/s6sRgGMLRQAuOfvmpgu8lIuCMGaWAOQeLrHHow=; b=x4KMUEi6euKbbOxz6uCp1po4atzgq6f4FL19t3Ws9Rz0RTmp/miH0rR/a6JkB6zy3q yi3rkYe0L3TIrTtelNNC7EodjyWHVj96GurimecJ1iVWzxAp9WNNsfeXi/UzjvTVE/t3 phEp71U25z8Q5xxrOpCjT6SG8v4ljp0l5GqS4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=Tk2u/s6sRgGMLRQAuOfvmpgu8lIuCMGaWAOQeLrHHow=; b=t6gfDDiXyKYyq6GcNlLjILlG1SW5n/NuSGdhVFvJKk216nhMQAY0IIfu6wDPYXZi2V 4GRM4OATunViSck9pg9AfT24AsJlE0FvgTUzH7ovxuC4UAlmPH5ZZXfCukVsNyw6oekh dBEr814OPp5DV6aI3FGUUxQN40tFHWze8+SWRHROjwQ9P3h6dXv1+FtikM5hy0S/4vlI VtJO0dxakdYtiFOHwycmIT8qcEHusmvVjXKeMYw1ck0ZhnU5rxkFvNjyOdS5yohOcqw8 wKUfTuCVulEIT8vnPmeGddnunZClbxcE6DkWJliRrT34E27Dxv4dLszxQXmFjDl//cDH mhwA== X-Gm-Message-State: ACrzQf02fDD/QlZUMv7+6Nx1VMoLnaBWgT0NalXi/DExCdua1suyTJsZ ny+78Uo8/xoecBij7goilhS63A== X-Received: by 2002:ac8:5bd5:0:b0:35c:b058:92ec with SMTP id b21-20020ac85bd5000000b0035cb05892ecmr6453244qtb.83.1663366755199; Fri, 16 Sep 2022 15:19:15 -0700 (PDT) Received: from localhost (228.221.150.34.bc.googleusercontent.com. [34.150.221.228]) by smtp.gmail.com with ESMTPSA id u16-20020a05620a0c5000b006bbe7ded98csm7132509qki.112.2022.09.16.15.19.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 16 Sep 2022 15:19:14 -0700 (PDT) Date: Fri, 16 Sep 2022 22:19:14 +0000 From: Joel Fernandes To: Frederic Weisbecker Cc: linux-kernel@vger.kernel.org, Josh Triplett , Lai Jiangshan , Mathieu Desnoyers , Neeraj Upadhyay , "Paul E. McKenney" , rcu@vger.kernel.org, Steven Rostedt Subject: Re: [PATCH rcu/next 2/3] rcu: Move trace_rcu_callback() before bypassing Message-ID: References: <20220915001419.55617-1-joel@joelfernandes.org> <20220915001419.55617-3-joel@joelfernandes.org> <20220916110949.GB25456@lothringen> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220916110949.GB25456@lothringen> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS 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 9/16/2022 7:09 AM, Frederic Weisbecker wrote: > On Thu, Sep 15, 2022 at 12:14:18AM +0000, Joel Fernandes (Google) wrote: >> If any CB is queued into the bypass list, then trace_rcu_callback() does >> not show it. This makes it not clear when a callback was actually >> queued, as you only end up getting a trace_rcu_invoke_callback() trace. >> Fix it by moving trace_rcu_callback() before >> trace_rcu_nocb_try_bypass(). >> >> Signed-off-by: Joel Fernandes (Google) >> --- >> kernel/rcu/tree.c | 10 ++++++---- >> 1 file changed, 6 insertions(+), 4 deletions(-) >> >> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c >> index 5ec97e3f7468..9fe581be8696 100644 >> --- a/kernel/rcu/tree.c >> +++ b/kernel/rcu/tree.c >> @@ -2809,10 +2809,7 @@ void call_rcu(struct rcu_head *head, rcu_callback_t >> func) >> } >> >> check_cb_ovld(rdp); >> - if (rcu_nocb_try_bypass(rdp, head, &was_alldone, flags)) >> - return; // Enqueued onto ->nocb_bypass, so just leave. >> - // If no-CBs CPU gets here, rcu_nocb_try_bypass() acquired >> ->nocb_lock. >> - rcu_segcblist_enqueue(&rdp->cblist, head); >> + >> if (__is_kvfree_rcu_offset((unsigned long)func)) >> trace_rcu_kvfree_callback(rcu_state.name, head, >> (unsigned long)func, >> @@ -2821,6 +2818,11 @@ void call_rcu(struct rcu_head *head, rcu_callback_t >> func) >> trace_rcu_callback(rcu_state.name, head, >> rcu_segcblist_n_cbs(&rdp->cblist)); >> >> + if (rcu_nocb_try_bypass(rdp, head, &was_alldone, flags)) >> + return; // Enqueued onto ->nocb_bypass, so just leave. >> + // If no-CBs CPU gets here, rcu_nocb_try_bypass() acquired >> ->nocb_lock. >> + rcu_segcblist_enqueue(&rdp->cblist, head); >> + >> trace_rcu_segcb_stats(&rdp->cblist, TPS("SegCBQueued")); >> >> /* Go handle any RCU core processing required. */ > > Two subtle changes induced here: > > * rcu_segcblist_n_cbs() is now read lockless. It's just tracing so no huge > deal > but still, if this races with callbacks invocation, we may on some rare > occasion > read stale numbers on traces while enqueuing (think about rcu_top for > example) Actually I disagree with this point now. Changes to the number of callbacks in the main ->cblist can be lockless. It uses atomic on CONFIG_RCU_NOCB. On non CONFIG_RCU_NOCB, CB cannot be queued as interrupts will be disabled. Also, in rcu_do_batch(), the count is manipulated after calling rcu_nocb_lock_irqsave(rdp, flags); > * trace_rcu_callback() will now show the number of callbacks _before_ > enqueuing > instead of _after_. Not sure if it matters, but sometimes tools rely on > trace > events. Yeah this is fixable and good point. So how about the below? ---8<----------------------- From: "Joel Fernandes (Google)" Subject: [PATCH] rcu: Call trace_rcu_callback() also for bypass queuing If any CB is queued into the bypass list, then trace_rcu_callback() does not show it. This makes it not clear when a callback was actually queued, as you only end up getting a trace_rcu_invoke_callback() trace. Fix it by calling the tracing function even for bypass queue. Also, while at it, optimize the tracing so that rcu_state is not accessed here if tracing is disabled, because that's useless if we are not tracing. A quick inspection of the generated assembler shows that rcu_state is accessed even if the jump label for the tracepoint is disabled. __trace_rcu_callback: movq 8(%rdi), %rcx movq rcu_state+3640(%rip), %rax movq %rdi, %rdx cmpq $4095, %rcx ja .L3100 movq 192(%rsi), %r8 1:jmp .L3101 # objtool NOPs this .pushsection __jump_table, "aw" .balign 8 .long 1b - . .long .L3101 - . .quad __tracepoint_rcu_kvfree_callback+8 + 2 - . .popsection With this change, the jump label check which is NOOPed is moved to the beginning of the function. Signed-off-by: Joel Fernandes (Google) --- kernel/rcu/tree.c | 31 +++++++++++++++++++++++-------- 1 file changed, 23 insertions(+), 8 deletions(-) diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 5ec97e3f7468..b64df55f7f55 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -2728,6 +2728,23 @@ static void check_cb_ovld(struct rcu_data *rdp) raw_spin_unlock_rcu_node(rnp); } +/* + * Trace RCU callback helper, call after enqueuing callback. + * The ->cblist must be locked when called. + */ +void __trace_rcu_callback(struct rcu_head *head, + struct rcu_data *rdp) +{ + if (trace_rcu_kvfree_callback_enabled() && + __is_kvfree_rcu_offset((unsigned long)head->func)) + trace_rcu_kvfree_callback(rcu_state.name, head, + (unsigned long)head->func, + rcu_segcblist_n_cbs(&rdp->cblist)); + else if (trace_rcu_callback_enabled()) + trace_rcu_callback(rcu_state.name, head, + rcu_segcblist_n_cbs(&rdp->cblist)); +} + /** * call_rcu() - Queue an RCU callback for invocation after a grace period. * @head: structure to be used for queueing the RCU updates. @@ -2809,17 +2826,15 @@ void call_rcu(struct rcu_head *head, rcu_callback_t func) } check_cb_ovld(rdp); - if (rcu_nocb_try_bypass(rdp, head, &was_alldone, flags)) + + if (rcu_nocb_try_bypass(rdp, head, &was_alldone, flags)) { + __trace_rcu_callback(head, rdp); return; // Enqueued onto ->nocb_bypass, so just leave. + } + // If no-CBs CPU gets here, rcu_nocb_try_bypass() acquired ->nocb_lock. rcu_segcblist_enqueue(&rdp->cblist, head); - if (__is_kvfree_rcu_offset((unsigned long)func)) - trace_rcu_kvfree_callback(rcu_state.name, head, - (unsigned long)func, - rcu_segcblist_n_cbs(&rdp->cblist)); - else - trace_rcu_callback(rcu_state.name, head, - rcu_segcblist_n_cbs(&rdp->cblist)); + __trace_rcu_callback(head, rdp); trace_rcu_segcb_stats(&rdp->cblist, TPS("SegCBQueued")); -- 2.37.3.968.ga6b4b080e4-goog