Received: by 2002:a05:7412:d024:b0:f9:90c9:de9f with SMTP id bd36csp97053rdb; Wed, 20 Dec 2023 07:13:46 -0800 (PST) X-Google-Smtp-Source: AGHT+IFinIhQUqQB9x1uTESFLNy9QtPOL0jMHk1dq9R5u/3HNol93wKDsyvhWbtOXWpHPp/ofbSC X-Received: by 2002:a1f:734a:0:b0:4b6:f0f7:1b44 with SMTP id o71-20020a1f734a000000b004b6f0f71b44mr976594vkc.30.1703085226232; Wed, 20 Dec 2023 07:13:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1703085226; cv=none; d=google.com; s=arc-20160816; b=R74I50FdSZgpWLkkIeGYvtz3pXLUWmUdEYgw/rBBkZ6196eTlgsOwQiPxIQ/zH9Krz qZLpWqNaFU/+YW5wGfMUTItLzlr2E3Ue5co5Yz1E1FStfvBqNsf0VHZqUI0YGPZBwlig w2nNYs0VHirhYRghNVamfVp8lmHf8n9ac2MG5GQCY2lO1x7WzFCq8jcV/Qt+wZgtpodQ AXeMhy8VR71kYCVq+UahrkNw48jtssg+mN5B1G3++msloxeV4RQ3tXZy3N9KxmdgLLnu RCu6D9c/7i+C8iY3g2Db14CKUQinkJq28VjrWknVlhdHr6nUmLRhxfuH4fkFRTubZMkZ x/hQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :references:message-id:subject:cc:to:from:date:dkim-signature; bh=kL54voj5IhDrxmA7aommogntybSJpf3fi3Nv46mX6yQ=; fh=y87ygauv+AZQqNpQB89VGAwvPwPwNwkKwpPzRwiS8D0=; b=xbVz0f0qEl2t5xTvSS/Jh4MnqZ/n21AJB1OE/C5Nf4pnq6CKY9bbSkKKnvKF52LfhZ tp01bUAWHeHAJjnP+cpCF/4iw0bAbY8KXIaj9xrLhV5OKdOzNOoHXu+c4yRis9IQ0TDD 8bDtqBDPe2olYWZOZ4lq3HBpr/v/ikvLcb9qbFlmiuiQylNB8oVKl2bn0x9rDwqDoutt FexRYOu7LHMC82rHNl4eXVyK+gBWYP8f5AYWj3ax86o6HbGiUPtovi+E1cpIkrMMGg3+ UjuocwK9iX/eQCviuwUDMm77woKNot0zFB4zkt8jkbR/i9bZpwcBVe5/sWusTVP1iARl rJaQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=qsY9ra43; spf=pass (google.com: domain of linux-kernel+bounces-7123-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-7123-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id r6-20020a67cd86000000b00466a99e428asi677231vsl.584.2023.12.20.07.13.46 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Dec 2023 07:13:46 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-7123-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=qsY9ra43; spf=pass (google.com: domain of linux-kernel+bounces-7123-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-7123-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id EBEB61C21E8A for ; Wed, 20 Dec 2023 15:13:45 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 463913FE4E; Wed, 20 Dec 2023 15:13:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qsY9ra43" X-Original-To: linux-kernel@vger.kernel.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7AF713FE20; Wed, 20 Dec 2023 15:13:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 73A03C433CA; Wed, 20 Dec 2023 15:13:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1703085208; bh=/+MAcPao4wtjkMts1SExJcD8F6yLGaio/sY+28LaI28=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=qsY9ra431T7DRLGYWiDKTx7uTDleRQxmD3gjgAt+wmEe8Aa0JFyKFOn9nEfzDRLyI A9IEMDflFp2uDOQOIlXtpniL+7tn2nu9lRbsvCRfZd86Pzxzso5FCDSPfId/thHD9T qXZNZ6BkqGGUI5XkTgQTTeBMeAvtygWDlK1/or0vrpTPafbXFT6jL3k7KeaqJ2pRV/ nCZ1EowaVM7aptWFnz/e4kDb4iVodjwK5qDbP3djgs4VMmpfEwa0iweeKmfJ9J9UQM hAnxBt8L0lNBM33yG71ZEbcfNZm/lbcssxnzAHrb5EpB8y3cjC88duzYzQcRgVBF45 Y1urUrjEYFY+A== Date: Wed, 20 Dec 2023 16:13:24 +0100 From: Frederic Weisbecker To: Z qiang Cc: LKML , Boqun Feng , Joel Fernandes , Neeraj Upadhyay , Uladzislau Rezki , rcu , "Paul E . McKenney" , Thomas Gleixner , Peter Zijlstra Subject: Re: [PATCH 2/3] rcu: Defer RCU kthreads wakeup when CPU is dying Message-ID: References: <20231218231916.11719-1-frederic@kernel.org> <20231218231916.11719-3-frederic@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Le Wed, Dec 20, 2023 at 04:24:35PM +0800, Z qiang a ?crit : > > > > When the CPU goes idle for the last time during the CPU down hotplug > > process, RCU reports a final quiescent state for the current CPU. If > > this quiescent state propagates up to the top, some tasks may then be > > woken up to complete the grace period: the main grace period kthread > > and/or the expedited main workqueue (or kworker). > > > > If those kthreads have a SCHED_FIFO policy, the wake up can indirectly > > arm the RT bandwith timer to the local offline CPU. Since this happens > > after hrtimers have been migrated at CPUHP_AP_HRTIMERS_DYING stage, the > > timer gets ignored. Therefore if the RCU kthreads are waiting for RT > > bandwidth to be available, they may never be actually scheduled. > > > > In the rcutree_report_cpu_dead(), the rcuog kthreads may also be wakeup in > do_nocb_deferred_wakeup(), if the rcuog kthreads is rt-fifo and wakeup happen, > the rt_period_active is set 1 and enqueue hrtimer to offline CPU in > do_start_rt_bandwidth(), > after that, we invoke swake_up_one_online() send ipi to online CPU, due to the > rt_period_active is 1, the rt-bandwith hrtimer will not enqueue to online CPU. > any thoughts? Duh, you're right, that one too. How many more? This hrtimer situation is scary... Thanks.