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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9F2B4ECAAA1 for ; Tue, 6 Sep 2022 19:11:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229759AbiIFTLZ (ORCPT ); Tue, 6 Sep 2022 15:11:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36630 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229721AbiIFTLU (ORCPT ); Tue, 6 Sep 2022 15:11:20 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C7C9DA2D97; Tue, 6 Sep 2022 12:11:15 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 45657B819F7; Tue, 6 Sep 2022 19:11:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 900FEC433C1; Tue, 6 Sep 2022 19:11:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1662491472; bh=I2thZSdsMA3fAvQeM9frwdjRPaDPr7Ghu/hTt+TPzy4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=hCJaUttRCTAa7ZyovROYIPZpH2DCmCqtP430NHFmrESACmlK0JcaP0r69c1ZtfYYl S2oH/cGOWmqUyrsz9IwSmehKBiiG9pd0F9fEOkfDRIUEXiTpmFrbDpwcJM1vSh8DDZ Esatx2eS7D2pdwLmRw4aZTcAcC5zLn4ozmz4n4yGVP2JTqmF4bHQ8MuzK6X9rXnONY LcyYoMstLFMVGz2RJ4p1lazjpapwQcXpCzxblRMW+7I85//IVSie++B0fVDAWbzubg E0YAUtQV/2/CUI9XS4EKysseVpwdf/bW5e0vV4e/1Z9ukNFkk0PXPsm4VlS4x4wBuO mbfkvFFtUzieA== Date: Tue, 6 Sep 2022 21:11:10 +0200 From: Frederic Weisbecker To: Joel Fernandes Cc: rcu@vger.kernel.org, linux-kernel@vger.kernel.org, rushikesh.s.kadam@intel.com, urezki@gmail.com, neeraj.iitr10@gmail.com, paulmck@kernel.org, rostedt@goodmis.org, vineeth@bitbyteword.org, boqun.feng@gmail.com Subject: Re: [PATCH v5 06/18] rcu: Introduce call_rcu_lazy() API implementation Message-ID: <20220906191110.GA187950@lothringen> References: <20220901221720.1105021-1-joel@joelfernandes.org> <20220901221720.1105021-7-joel@joelfernandes.org> <20220902152132.GA115525@lothringen> <20220906151757.GA183806@lothringen> <64f5770c-df37-8975-200d-7908de23fa73@joelfernandes.org> <4f6061f0-0de7-2916-dc6e-9f5af9b944c0@joelfernandes.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4f6061f0-0de7-2916-dc6e-9f5af9b944c0@joelfernandes.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 06, 2022 at 12:43:52PM -0400, Joel Fernandes wrote: > On 9/6/2022 12:38 PM, Joel Fernandes wrote: > Ah, now I know why I got confused. I *used* to flush the bypass list before when > !lazy CBs showed up. Paul suggested this is overkill. In this old overkill > method, I was missing a wake up which was likely causing the boot regression. > Forcing a wake up fixed that. Now in v5 I make it such that I don't do the flush > on a !lazy rate-limit. > > I am sorry for the confusion. Either way, in my defense this is just an extra > bit of code that I have to delete. This code is hard. I have mostly relied on a > test-driven development. But now thanks to this review and I am learning the > code more and more... Yeah this code is hard. Especially as it's possible to flush from both sides and queue the timer from both sides. And both sides read the bypass/lazy counter locklessly. But only call_rcu_*() can queue/increase the bypass size whereas only nocb_gp_wait() can cancel the timer. Phew! Among the many possible dances between rcu_nocb_try_bypass() and nocb_gp_wait(), I haven't found a way yet for the timer to be set to LAZY when it should be BYPASS (or other kind of accident such as an ignored callback). In the worst case we may arm an earlier timer than necessary (RCU_NOCB_WAKE_BYPASS instead of RCU_NOCB_WAKE_LAZY for example). Famous last words... > Thanks, > > - Joel > > >