Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp1504340pxb; Fri, 1 Oct 2021 12:04:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz4HasGC4HFtUt75dRSi3iHU+nQVfYzGGgLrKhNYY/IxMRMKW5iwpuJVBZQ2y51DfuGYpOI X-Received: by 2002:a17:902:7684:b0:13d:e9ec:b467 with SMTP id m4-20020a170902768400b0013de9ecb467mr10741869pll.77.1633115065162; Fri, 01 Oct 2021 12:04:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633115065; cv=none; d=google.com; s=arc-20160816; b=B8SlD4heoKrjBbGdMVTpkEbk5FaoPX46glVqHEGLX74qwhNV8/BW86knjiz39pm0kz 4eJwW53mBOlcgI7DSrE0rt2SMPSodlL8cF6038oc4X6FCxEAu5LCZako3t8r8/ixIaJo gEStT1Hpx6F0oOGLpeNYm7BIl4Fk97jJATCyE660U7ojqnYE2VmgG5Nut3QHoo0K7fuu 9SG8acKa2xPFePL98862ogXktpScP0Jr1OTKZ4f6ONnDabRYRy5UV6UlbD6twE9+/hM/ 9gztViXMCK4r5JeKPFzege+5rPDxvKgJTcqb27E+aYkjygFGYFEMqx8BmnDTbBu6Hwb9 BddQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=GUhGuTooeyrv+a/qkPsR7roBhBAnKPsZ4kzjNSr3shc=; b=aS1ZFdv3kFYAqexMTqJ2ET3ykeRGD9SESOUQNXMWJCilh/GwdJhDDbmMnEpsTf+Kt/ uj5qL5GaAscAdPIi7602AvZLYLoGTm2CgRYlnZ8wOtZ1Cvxi3LwWogVURnDOCZcudyNu uQUXXkDrJ+hxC3ogoIkd8bjpZQBCOnCXR1h2jVqBBQ+4Ad46x7klGLxCKzZXIPtSQKsj /N8OrT94nMvc1w9fsB8DrE4ioqEGg6jtNp6AkHytFSZ090/UJk3OiCFqwxAo0ILCk/yy tqSGwLLGxLv1Vd5NwETI69HDf420PzBXcpbKU/yABCdW/1OD9qfdSbpNsnPKH98tDP6O 0gqg== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c19si8505843pls.309.2021.10.01.12.04.10; Fri, 01 Oct 2021 12:04:25 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1355237AbhJARw5 (ORCPT + 99 others); Fri, 1 Oct 2021 13:52:57 -0400 Received: from foss.arm.com ([217.140.110.172]:49506 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1355478AbhJARw4 (ORCPT ); Fri, 1 Oct 2021 13:52:56 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 1CCF1106F; Fri, 1 Oct 2021 10:51:12 -0700 (PDT) Received: from e113632-lin (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6E2233F70D; Fri, 1 Oct 2021 10:51:10 -0700 (PDT) From: Valentin Schneider To: Frederic Weisbecker , "Paul E . McKenney" Cc: LKML , Frederic Weisbecker , Sebastian Andrzej Siewior , Peter Zijlstra , Uladzislau Rezki , Thomas Gleixner , Boqun Feng , Neeraj Upadhyay , Josh Triplett , Joel Fernandes , rcu@vger.kernel.org Subject: Re: [PATCH 08/11] rcu/nocb: Limit number of softirq callbacks only on softirq In-Reply-To: <20210929221012.228270-9-frederic@kernel.org> References: <20210929221012.228270-1-frederic@kernel.org> <20210929221012.228270-9-frederic@kernel.org> Date: Fri, 01 Oct 2021 18:51:08 +0100 Message-ID: <877dewmy5v.mognet@arm.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 30/09/21 00:10, Frederic Weisbecker wrote: > The current condition to limit the number of callbacks executed in a > row checks the offloaded state of the rdp. Not only is it volatile > but it is also misleading: the rcu_core() may well be executing > callbacks concurrently with NOCB kthreads, and the offloaded state > would then be verified on both cases. As a result the limit would > spuriously not apply anymore on softirq while in the middle of > (de-)offloading process. > > Another issue with the condition is that rcu_is_callbacks_kthread() > doesn't check if we are actually running callbacks from rcuc itself or > from a softirq interrupting rcuc. > Doesn't rcutree.use_softirq imply rcuc is never woken, in which case RCU_SOFTIRQ can't interrupt rcuc (e.g. while run atop an IRQ exit)? I suppose during the (de)offload sequence we could have RCU_SOFTIRQ running atop the NOCB CB kthread, but that's not something rcu_is_callbacks_kthread() detects. Also, why is rcu_is_callbacks_kthread() hardcoded to false for !CONFIG_RCU_BOOST? Isn't it relevant for do_rcu_batch() ratelimiting regardless (at least before your patches)?