Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp1910359pxj; Wed, 19 May 2021 17:27:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyGjVCFGywjVtabQod378QjcXpDoYCJ3ae/pVcAIZMn737mwMXF4w2nx+YvA1STDbhJs9rd X-Received: by 2002:a05:6e02:10c6:: with SMTP id s6mr2309103ilj.15.1621470455537; Wed, 19 May 2021 17:27:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621470455; cv=none; d=google.com; s=arc-20160816; b=hSPdNw+J2kLrtpgtJN59Ak8DBYxz2SKgxZZ9KgezQmOh3YmqvD4r7HCitknogPuB5N BvnwU8nHBTJ9yG7pVkZQ2ZC2EIT1Cs6B9Cveb5esScr1ItkS8KwQLKcEr/cF7zhVhKcT FmHzBsM0km0sBbIrmteEeTL9GA9r2OJ5/8whYtYWl0bdm2jY5MHrENXyLf70mWZuLI/3 5fZa4VcdJHZ4M3Pbs9/MMQ5rcUCHg1tZ9OiVjNgsoRt6nu0N//SA+LuKiIy5jMvWeL3D fg4vc22CKG9EU6s2TAkS0vsy8KRUVzYAFJmW3Sf1XGdTZUcj6AnUlE6TPSu9LkPy7Gms +gbg== 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=96j5ldVdJ+W16wPjc3OPXG5Xv+70ZAwZtEfYu7hbi5A=; b=TvoL0l/27u3VSMkAYkvO2GBStRQMMuwplrwW8KyVJzVuRD7PLNP8n05R4zYALYVwuO df7CFKQzB9wNA9N88aDi/EenoRoh1XFBd8yff5mKbTQ2KFrZiQb9aWC8hxFktSKSu8Y9 7IRuBUO9fGsHEvwDlv8yI7N9PHIbLa01ImM0IKdnECL/s3fyhJYkoiGBHlpQ02r28Ge4 h9IYTTmhwZPR3uFxdqFniiDgHNmUF/DL1fL/mLdx1L2i4VcnYH3Sb0iZdQSFn6WO+Ui4 L//U28OVSI4qKXyf5lutbK+oc7ULmbJegIV94ZQm9TPGMvqQHCx+uub1mfqbMhpsi6+n h5ZQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="p8P/h7uY"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x7si954760jat.98.2021.05.19.17.27.22; Wed, 19 May 2021 17:27:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="p8P/h7uY"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230226AbhETA1R (ORCPT + 99 others); Wed, 19 May 2021 20:27:17 -0400 Received: from mail.kernel.org ([198.145.29.99]:53104 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230148AbhETA1Q (ORCPT ); Wed, 19 May 2021 20:27:16 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id C78E1613AC; Thu, 20 May 2021 00:25:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1621470356; bh=kxi2FW4GOYHlCiXzfLRe6LmjwHpcxDDms7TCiymAhi8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=p8P/h7uYI5lmQS1oT1Eht3e51fUfFq62DfE23qQDPMmAiZjdhNNTuXNati0Li0H6U 9wbRExz60HHNOjrO60Sc+RRuMA4UIGhE5KHaCZvBL4Op1wEPvzeY7R9JUpyBY0AneJ QPYAQI/+xWkkTkkLmXT24mWErS8vvZfr04IYteENDLC3VQpm+H0lVSptsgjQSUMLPv qhKQA2NWT6+BMkaBENZ/tQt6UwqDhzOC9WKSIeCnzBKcAM3pHogrzdF0XMwtZ2LiXM hQd/+wqZNpSUeWbZxKqTBedrlumtrQRxljSx1DlwJ8VQOoKWVgBXJXApMJfXEVOXwh 6feVqsFTi7S5w== Date: Thu, 20 May 2021 02:25:53 +0200 From: Frederic Weisbecker To: "Paul E. McKenney" Cc: LKML , rcu@vger.kernel.org Subject: Re: [PATCH 2/3] rcu/nocb: Remove NOCB deferred wakeup from rcutree_dead_cpu() Message-ID: <20210520002553.GA22836@lothringen> References: <20210519000930.15702-1-frederic@kernel.org> <20210519000930.15702-3-frederic@kernel.org> <20210519155905.GY4441@paulmck-ThinkPad-P17-Gen-1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210519155905.GY4441@paulmck-ThinkPad-P17-Gen-1> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 19, 2021 at 08:59:05AM -0700, Paul E. McKenney wrote: > On Wed, May 19, 2021 at 02:09:29AM +0200, Frederic Weisbecker wrote: > > At CPU offline time, we make sure to flush any pending wakeup for the > > nocb_gp kthread linked to the outgoing CPU. > > > > Now we are making sure of that twice: > > > > 1) From rcu_report_dead() when the outgoing CPU makes the very last > > local cleanups by itself before switching offline. > > > > 2) From rcutree_dead_cpu(). Here the offlining CPU has gone and is truly > > now offline. Another CPU takes care of post-portem cleaning up and > > check if the offline CPU had pending wakeup. > > > > Both ways are fine but we have to choose one or the other because we > > don't need to repeat that action. Simply benefit from cache locality > > and keep only the first solution. > > But between those two calls, the CPU takes a full pass through the > scheduler and heads into the idle loop. What if there is a call_rcu() > along the way, and if this was the last online CPU in its rcuog kthread's > group of CPUs? Wouldn't that callback be stranded until one of those > CPUs came back online? Nope, rcu_report_dead() is called from the idle path right before arch_cpu_idle_dead(). There should be no call to the scheduler until the CPU comes back online. Thanks!