Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp444080pxb; Wed, 6 Oct 2021 08:14:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJznJMO2HjT7BOJKmSWfIdohhoa19sFYt+IrKLJiPigS+MTgyOuyBMemW5tx9AqSbiF3HEDC X-Received: by 2002:a05:6402:1d04:: with SMTP id dg4mr34696659edb.183.1633533255965; Wed, 06 Oct 2021 08:14:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633533255; cv=none; d=google.com; s=arc-20160816; b=FWhpBvBD53O38LprSzOcH26AsBtquiiO7N/LDMvaK+d2Zo+h9P0m3y58Q4kt84/BXC cL6Ib2NrsQPW1uGKX0Kwatje0U0UQ/JYuMgIK9WL3LSBzFtrp8QuNpjkiuxz/ikBkBoq eRSNW35lIypanEuNyhwBYdemqGUoa0LmctuNl1VPiqZxhDjumc/viL/k7HHpHDWpUS/+ 8gWlCX/OCmfb7sefKRMzwnfiALpkQHZGk6lH+wJx8SY9N0ZtIVmn3yjRcbi0bQRR0qVp J6f7IDvQETNHNLYQ4ok6y9vsr882C2HAjIGePzsL8CaVjUsqHijCYqX+Oj2T+lZuMdLl B0ZQ== 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=ngpmFMrOPAgaPZTaANSvrvMFMmnVrzSeO1HjBCihuRA=; b=JysRUmps2XdIsHwG7FfJy474ZLFjCYP87y2jwBeOQRvWWxzrihp2Yq/QHzj07arpH8 F+NF8WbhdWNHpvqRoNs/rCHg5V8nt6j3VyYN7pn4xXGJOcWrq6WkBIwaDtLL8dJhaXDH cMLn++MPeW8hrcNwhBnNSAx4no+Q82AXTyfqj1wwRKyHZT4aYK4hL+E9plH9rMKM4rKU 3OA3k7CTd6L6n/QfLFKPY5VdgtA8/GDRYsaX4KBzerewzo+ut7xM/WuVz/aMear1b66E 9TuV+SoBC64T+AVyuARM5GJoUhd6zBgm5MW0lyAg2W2rfzEoML8KSn6UANQxQXeyda6a 2Xng== 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 c4si23386908ejc.492.2021.10.06.08.13.48; Wed, 06 Oct 2021 08:14:15 -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 S239017AbhJFPOJ (ORCPT + 99 others); Wed, 6 Oct 2021 11:14:09 -0400 Received: from foss.arm.com ([217.140.110.172]:35868 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230486AbhJFPOI (ORCPT ); Wed, 6 Oct 2021 11:14:08 -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 D0E706D; Wed, 6 Oct 2021 08:12:15 -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 485D23F66F; Wed, 6 Oct 2021 08:12:14 -0700 (PDT) From: Valentin Schneider To: Frederic Weisbecker Cc: "Paul E . McKenney" , LKML , Sebastian Andrzej Siewior , Peter Zijlstra , Uladzislau Rezki , Thomas Gleixner , Boqun Feng , Neeraj Upadhyay , Josh Triplett , Joel Fernandes , rcu@vger.kernel.org Subject: Re: [PATCH 10/11] rcu: Apply callbacks processing time limit only on softirq In-Reply-To: <20211004134748.GD273854@lothringen> References: <20210929221012.228270-1-frederic@kernel.org> <20210929221012.228270-11-frederic@kernel.org> <874ka0my57.mognet@arm.com> <20211004134748.GD273854@lothringen> Date: Wed, 06 Oct 2021 16:12:12 +0100 Message-ID: <87ilyakx0z.mognet@arm.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/10/21 15:47, Frederic Weisbecker wrote: > On Fri, Oct 01, 2021 at 06:51:32PM +0100, Valentin Schneider wrote: >> On 30/09/21 00:10, Frederic Weisbecker wrote: >> > Time limit only makes sense when callbacks are serviced in softirq mode >> > because: >> > >> > _ In case we need to get back to the scheduler, >> > cond_resched_tasks_rcu_qs() is called after each callback. >> > >> > _ In case some other softirq vector needs the CPU, the call to >> > local_bh_enable() before cond_resched_tasks_rcu_qs() takes care about >> > them via a call to do_softirq(). >> > >> > _ The time spent on other tasks after scheduling out, or on softirqs >> > processing, is spuriously accounted to the time limit. >> > >> >> That wasn't the case before ("rcu: Fix callbacks processing time limit >> retaining cond_resched()") > > But if cond_resched_tasks_rcu_qs() was called and then on the next iteration > tlimit is checked, the time spent scheduling out is included, right? > if tlimit was set, then that branch would either continue or break; both cases would have skipped over the cond_resched_tasks_rcu_qs() (which the aforementioned patch addresses).