Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp4595120iob; Sun, 8 May 2022 18:36:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw+RWZU77SLfn7Z3h9jYmN6vBLgRIQKVWnEDzozruoJVeyHP+TTTRF6TJvIFy10MuSjwwso X-Received: by 2002:a17:90b:3c4e:b0:1dc:9999:44eb with SMTP id pm14-20020a17090b3c4e00b001dc999944ebmr23731197pjb.179.1652060209613; Sun, 08 May 2022 18:36:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652060209; cv=none; d=google.com; s=arc-20160816; b=wmXlzyCrcq3EhjMKydzNyBHak+ybY021FcimSHK8GrVmtXwpztnPm7/CusKaN/AXfw NeVrDapUXgPBlwGDnH+WwK3ZdED81a+4WpkmuvzGhQrEs5cWc61qBEdVLu5GqIOty5zK QfzTBDdwY9RI8N412CdJTdeyoWnvzyPFNKEXka0+2WE2mT3VA3q4w9/5+iVr2tE9BQVv z0gdNK0bkFyMq+OoxR/kWaHbFv+uQvzWw0Pk/jvqxfhE/i3IqFy+pe3TK4iNE2ZoMSj5 z5KAxUJZkJov1XL3aKXGghxdAMjLsckgSKKM5jV1Bcq79jWiktdiIOBBYoAAn3K3YUyQ cAhw== 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:reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=yi7sS4u6eg1GdPPSR8p5DlQu5bJT69kBSJxFHoPN4Xw=; b=fZ3sWFjQvofUvZP8y26P17ZuwDRJiMkNmw0rbKPH6torzd/ZVPC6Gba4SSo1HeuQqU VgZMCVwGICuztViQI71ErSp4zJ+KseHDA0xchYz0tp28RBqIbnY2QzCJORw/ktYQc9MF i8abR3JRlHPmYjsfkBvNjC5QjBhSRK87cv87NwpVDdl1TIrhOObeByocryJ57wOeIP1J Y9KWb3ckYvTeLUUaQG/VC0o8J9r0m8RLdQvQlEzdXLJNJEzMD3a4+FPV6EaoyN01WIkm 5wWWnilgBMR+04Y9axh7cS2tTkirDUiprXide35+y2t4N9rfpQMHmcAIqZYNnlRgmfst TQyQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Rur4thgH; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id k25-20020a635619000000b003c6709779a9si7095633pgb.295.2022.05.08.18.36.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 May 2022 18:36:49 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Rur4thgH; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 8637133A17; Sun, 8 May 2022 18:36:06 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1384397AbiEETdr (ORCPT + 99 others); Thu, 5 May 2022 15:33:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46630 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1351650AbiEETdp (ORCPT ); Thu, 5 May 2022 15:33:45 -0400 Received: from sin.source.kernel.org (sin.source.kernel.org [IPv6:2604:1380:40e1:4800::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DC56B55492; Thu, 5 May 2022 12:30:04 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id 50F6ACE3090; Thu, 5 May 2022 19:30:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5D1C0C385A8; Thu, 5 May 2022 19:30:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1651779001; bh=vA5c3sAZlsEIF9GVy5xkKqdpy6kiCh58XJGgalns9Zk=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=Rur4thgH3tGLOLQ3PE4NfuLNRo6KD+P9KN8uPermkSvDV+RSnfCSVeH1+luL/JihO nIaKMx8E+70C9NaPk2/MAZdAwmLF4e3A1hfmi9UlnnnoTKQho8krlzE40Wbg6ZaHul OYtZXG3IuFld81DJDac/OHvgjqNqhrYnuLwwrWteLOCuvdNc9j5niJJLsBHQ8W0/2y z9RZTjaqQRQGFIYZLlW7IPHuyDZpURyxIuE/iYgA47tjeVy6ZJDQCR5NQRf+cScAmZ /RwMgI19giflsDT9cLsCAPRy/57WSVwMN2LGVT8+wgD6eawna6yodohAL9eQfWMj7U U+VdD4wj/hjYw== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 43FBA5C2CB7; Thu, 5 May 2022 12:29:56 -0700 (PDT) Date: Thu, 5 May 2022 12:29:56 -0700 From: "Paul E. McKenney" To: Zqiang Cc: frederic@kernel.org, rcu@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] rcu: Add rnp->cbovldmask check in rcutree_migrate_callbacks() Message-ID: <20220505192956.GX1790663@paulmck-ThinkPad-P17-Gen-1> Reply-To: paulmck@kernel.org References: <20220505155236.1559619-1-qiang1.zhang@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220505155236.1559619-1-qiang1.zhang@intel.com> X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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, May 05, 2022 at 11:52:36PM +0800, Zqiang wrote: > Currently, the rnp's cbovlmask is set in call_rcu(). when CPU going > offline, the outgoing CPU's callbacks is migrated to target CPU, the > number of callbacks on the my_rdp may be overloaded, if overload and > there is no call_rcu() call on target CPU for a long time, the rnp's > cbovldmask is not set in time. in order to fix this situation, add > check_cb_ovld_locked() in rcutree_migrate_callbacks() to help CPU more > quickly reach quiescent states. > > Signed-off-by: Zqiang Doesn't this get set right at the end of the current grace period? Given that there is a callback overload, there should be a grace period in progress. See this code in rcu_gp_cleanup(): if (rcu_is_leaf_node(rnp)) for_each_leaf_node_cpu_mask(rnp, cpu, rnp->cbovldmask) { rdp = per_cpu_ptr(&rcu_data, cpu); check_cb_ovld_locked(rdp, rnp); } So what am I missing here? Or are you planning to remove the above code? If so, wouldn't you also need to clear the indication for the CPU that is going offline, being careful to handle the case where the two CPUs have different leaf rcu_node structures? Thanx, Paul > --- > kernel/rcu/tree.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c > index 9dc4c4e82db6..bcc5876c9753 100644 > --- a/kernel/rcu/tree.c > +++ b/kernel/rcu/tree.c > @@ -4577,6 +4577,7 @@ void rcutree_migrate_callbacks(int cpu) > needwake = needwake || rcu_advance_cbs(my_rnp, my_rdp); > rcu_segcblist_disable(&rdp->cblist); > WARN_ON_ONCE(rcu_segcblist_empty(&my_rdp->cblist) != !rcu_segcblist_n_cbs(&my_rdp->cblist)); > + check_cb_ovld_locked(my_rdp, my_rnp); > if (rcu_rdp_is_offloaded(my_rdp)) { > raw_spin_unlock_rcu_node(my_rnp); /* irqs remain disabled. */ > __call_rcu_nocb_wake(my_rdp, true, flags); > -- > 2.25.1 >