Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38;
From:   Uladzislau Rezki <urezki@gmail.com>
Date:   Thu, 26 Oct 2023 17:14:16 +0200
To:     Frederic Weisbecker <frederic@kernel.org>
Cc:     Uladzislau Rezki <urezki@gmail.com>,
        "Paul E . McKenney" <paulmck@kernel.org>,
        RCU <rcu@vger.kernel.org>,
        Neeraj upadhyay <Neeraj.Upadhyay@amd.com>,
        Boqun Feng <boqun.feng@gmail.com>,
        Hillf Danton <hdanton@sina.com>,
        Joel Fernandes <joel@joelfernandes.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Oleksiy Avramchenko <oleksiy.avramchenko@sony.com>
Subject: Re: [PATCH 1/3] rcu: Reduce synchronize_rcu() waiting time
Message-ID: <ZTqCSOD5BlfZYh4T@pc636>
References: <20231025140915.590390-1-urezki@gmail.com>
 <20231025140915.590390-2-urezki@gmail.com>
 <ZTkwl0bzTTCy8g5N@localhost.localdomain>
 <ZTpi6diP4h84PtWE@pc636>
 <ZTp2Ge2ILOJ4VbYZ@lothringen>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZTp2Ge2ILOJ4VbYZ@lothringen>
Precedence: bulk

On Thu, Oct 26, 2023 at 04:22:17PM +0200, Frederic Weisbecker wrote:
> On Thu, Oct 26, 2023 at 03:00:25PM +0200, Uladzislau Rezki wrote:
> > On Wed, Oct 25, 2023 at 05:13:27PM +0200, Frederic Weisbecker wrote:
> > > > +	llist_for_each_safe(pos, head, head) {
> > > 
> > > Two times head intended here? There should be some
> > > temporary storage in the middle.
> > > 
> > Yes. It is intentially done. The head is updated, i.e. shifted to a next,
> > because we directly process users from a GP. The number is limited to 5
> > all the rest is deferred.
> 
> Ah ok.
> 
> > > So you can have:
> > > 
> > > * Queue to sr.curr is atomic fully ordered
> > > * Check and move from sr.curr to sr.wait is atomic fully ordered
> > > * Check from sr.wait can have a quick unatomic unordered
> > >   llist_empty() check. Then extract unatomic unordered as well.
> > > * If too many, move atomic/ordered to sr.done.
> > > 
> > > Am I missing something?
> > >
> > If too many move to done and kick the helper. The sr.wait can not
> > be touched until the rcu_sr_normal_gp_cleanup() is completed, i.e.:
> > 
> > <snip>
> > GP-kthread(same and one task context):
> >     rcu_sr_normal_gp_cleanup();
> >     wait for a grace period;
> >     rcu_sr_normal_gp_cleanup();
> > <snip>
> > 
> > Am i missing your point?
> 
> Yeah got it. My point was just that any manipulation of sr.wait can be
> done without atomic/ordered operations. Such as using __list_empty() and
> __llist_del_all().
> 
> Ah there is also the line:
> 
>    llist_add_batch(head, tail, &sr.wait);
> 
> in rcu_sr_normal_gp_init() that can be turned into __llist_add_batch()
> 
Thank you for the good input. Indeed we can manipulate sr.wait using
__llist* functions. I will update it accordingly. So, see your point.

Appreciate for your review!

--
Uladzislau Rezki