Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Uladzislau Rezki <urezki@gmail.com>
Date:   Fri, 4 Nov 2022 15:39:09 +0100
To:     Joel Fernandes <joel@joelfernandes.org>
Cc:     paulmck@kernel.org, Uladzislau Rezki <urezki@gmail.com>,
        rcu@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] rcu/kfree: Do not request RCU when not needed
Message-ID: <Y2UkDZDKXOaH9jA0@pc638.lan>
References: <ACF5E134-0C17-484B-AF9E-D4E6FAC9535F@joelfernandes.org>
 <B78EFE6F-D479-4F96-89CC-E19CA4146FF8@joelfernandes.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <B78EFE6F-D479-4F96-89CC-E19CA4146FF8@joelfernandes.org>
Precedence: bulk

> >> 
> >> Or am I missing something here?
> > 
> > Yeah I am with Paul on this, NAK on “blocking in kworker” instead of “checking for grace period + queuing either regular work or RCU work”. Note that blocking also adds a pointless and fully avoidable scheduler round trip.
> 
> As a side note, it’s notable how nicely this work evolved over the years thanks to Vlad and all of y’all’s work. For instance, flooding pages with kfree pointers and grace period polling was not something even invented back when kfree_rcu was a simple wrapper. Now it soon will be actually freeing memory faster, by avoiding waiting on RCU when not needed! And of course this is all happening probably because we wanted RCU to be lazy in nocb is a nice side effect of that effort ;-)
> 
Yep. We want sometimes everything to be lazy :)

--
Uladzislau Rezki