From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 584A1C4338F for ; Thu, 29 Jul 2021 10:53:33 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1D37B60C40 for ; Thu, 29 Jul 2021 10:53:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 1D37B60C40 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:References :In-Reply-To:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=+IcQEyLxD8arQoC0bRgIFupq4Z7Izbu9oKKPbS2smIs=; b=T9Q91pb9GB6k5R k4mpHxzMrzC/8/k50X/mpbKPlTri1BXtJAe1Ez3bmJ5n8eGvVcR819wvax1no7fOnv8WA27XG0JH0 mqqDmnFTdOmsqGolrIZ+oW1tCtoUv9olhomDWCg5j4gFO0CmtB9lVIcQ/3jybG6VuTid+afYIGGaz 9hIZGGln+Z2jRmWwSEfnFwn8PGVVnxzDQhoaupJhXHnAXq6uKqL3qioTTMlT0Y12QmhH8CcbtzO+B cNdvjzuovm4bOLay9wH8qcRMy4jvswVYKUI1qctlhLnGMPVTQ4xOPboHcyFMRNooc6eFTLQYFTAbA xBI4XeiaZFx1uLYuTMOA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m93dj-003tGB-Jt; Thu, 29 Jul 2021 10:51:47 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m93dd-003tEd-GX for linux-arm-kernel@lists.infradead.org; Thu, 29 Jul 2021 10:51:43 +0000 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 1196E6D; Thu, 29 Jul 2021 03:51:40 -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 476353F66F; Thu, 29 Jul 2021 03:51:37 -0700 (PDT) From: Valentin Schneider To: paulmck@kernel.org, Frederic Weisbecker Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rt-users@vger.kernel.org, Catalin Marinas , Will Deacon , Ingo Molnar , Peter Zijlstra , Thomas Gleixner , Steven Rostedt , Daniel Bristot de Oliveira , Josh Triplett , Mathieu Desnoyers , Lai Jiangshan , Joel Fernandes , Anshuman Khandual , Vincenzo Frascino , Steven Price , Ard Biesheuvel , Sebastian Andrzej Siewior Subject: Re: [PATCH 2/3] rcu/nocb: Check for migratability rather than pure preemptability In-Reply-To: <20210729010445.GO4397@paulmck-ThinkPad-P17-Gen-1> References: <20210721115118.729943-1-valentin.schneider@arm.com> <20210721115118.729943-3-valentin.schneider@arm.com> <20210727230814.GC283787@lothringen> <87pmv2kzbd.mognet@arm.com> <20210728220137.GD293265@lothringen> <20210729010445.GO4397@paulmck-ThinkPad-P17-Gen-1> Date: Thu, 29 Jul 2021 11:51:32 +0100 Message-ID: <87mtq5l7ez.mognet@arm.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210729_035141_720405_175BB6AB X-CRM114-Status: GOOD ( 26.64 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 28/07/21 18:04, Paul E. McKenney wrote: > On Thu, Jul 29, 2021 at 12:01:37AM +0200, Frederic Weisbecker wrote: >> On Wed, Jul 28, 2021 at 08:34:14PM +0100, Valentin Schneider wrote: >> > Now, if the offloaded state was (properly) protected by a local_lock, do >> > you reckon we could then keep preemption enabled? >> >> I guess we could take such a local lock on the update side >> (rcu_nocb_rdp_offload) and then take it on rcuc kthread/softirqs >> and maybe other places. >> >> But we must make sure that rcu_core() is preempt-safe from a general perspective >> in the first place. From a quick glance I can't find obvious issues...yet. >> >> Paul maybe you can see something? > > Let's see... > > o Extra context switches in rcu_core() mean extra quiescent > states. It therefore might be necessary to wrap rcu_core() > in an rcu_read_lock() / rcu_read_unlock() pair, because > otherwise an RCU grace period won't wait for rcu_core(). > > Actually, better have local_bh_disable() imply > rcu_read_lock() and local_bh_enable() imply rcu_read_unlock(). > But I would hope that this already happened. It does look like it. > > o The rcu_preempt_deferred_qs() check should still be fine, > unless there is a raw_bh_disable() in -rt. > > o The set_tsk_need_resched() and set_preempt_need_resched() > might preempt immediately. I cannot think of a problem > with that, but careful testing is clearly in order. > > o The values checked by rcu_check_quiescent_state() could now > change while this function is running. I don't immediately > see a problematic sequence of events, but here be dragons. > I therefore suggest disabling preemption across this function. > Or if that is impossible, taking a very careful look at the > proposed expansion of the state space of this function. > > o I don't see any new races in the grace-period/callback check. > New callbacks can appear in interrupt handlers, after all. > > o The rcu_check_gp_start_stall() function looks similarly > unproblematic. > > o Callback invocation can now be preempted, but then again it > recently started being concurrent, so this should be no > added risk over offloading/de-offloading. > > o I don't see any problem with do_nocb_deferred_wakeup(). > > o The CONFIG_RCU_STRICT_GRACE_PERIOD check should not be > impacted. > > So some adjustments might be needed, but I don't see a need for > major surgery. > > This of course might be a failure of imagination on my part, so it > wouldn't hurt to double-check my observations. > I'll go poke around, thank you both! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel