linux-kernel - Re: [PATCH 1/3] rcu: Reduce synchronize

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZTp2Ge2ILOJ4VbYZ@lothringen>
Date:   Thu, 26 Oct 2023 16:22:17 +0200
From:   Frederic Weisbecker <frederic@...nel.org>
To:     Uladzislau Rezki <urezki@...il.com>
Cc:     "Paul E . McKenney" <paulmck@...nel.org>,
        RCU <rcu@...r.kernel.org>,
        Neeraj upadhyay <Neeraj.Upadhyay@....com>,
        Boqun Feng <boqun.feng@...il.com>,
        Hillf Danton <hdanton@...a.com>,
        Joel Fernandes <joel@...lfernandes.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Oleksiy Avramchenko <oleksiy.avramchenko@...y.com>
Subject: Re: [PATCH 1/3] rcu: Reduce synchronize_rcu() waiting time

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()

Thanks.