linux-kernel - Re: [PATCH] simplify/improve rcu batch tuning

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: <20060908163022.GA149@oleg>
Date:	Fri, 8 Sep 2006 20:30:22 +0400
From:	Oleg Nesterov <oleg@...sign.ru>
To:	"Paul E. McKenney" <paulmck@...ibm.com>
Cc:	Dipankar Sarma <dipankar@...ibm.com>,
	Srivatsa Vaddagiri <vatsa@...ibm.com>,
	Eric Dumazet <dada1@...mosbay.com>,
	"David S. Miller" <davem@...emloft.net>,
	Linus Torvalds <torvalds@...l.org>,
	Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org,
	josht@...ibm.com
Subject: Re: [PATCH] simplify/improve rcu batch tuning

On 09/08, Paul E. McKenney wrote:
>
> On Fri, Sep 08, 2006 at 03:39:30PM +0400, Oleg Nesterov wrote:
> > >
> > Actually I think it also makes sense to do tasklet_schedule(rcu_tasklet)
> > in call_rcu(), this way we can detect that we need to start the next batch
> > earlier.
> 
> As long as we don't do this too often...  One way to prevent doing this
> too often would be to check rcp->completed against rdp->batch similarly
> to __rcu_process_callbacks()'s checks.  In call_rcu(), perhaps something
> like the following inside the ->qlen check:
> 
> 	if (__rcu_pending(&rcu_ctrlblk, rdp) {
> 		tasklet_schedule(&per_cpu(rcu_tasklet, rdp->cpu));
> 	}

Yes.

> > > > @@ -297,6 +294,7 @@ static void rcu_start_batch(struct rcu_c
> > > >  		smp_mb();
> > > >  		cpus_andnot(rcp->cpumask, cpu_online_map, nohz_cpu_mask);
> > > >
> > > > +		rcp->signaled = 0;
> > >
> > > Would it make sense to invoke force_quiescent_state() here in the
> > > case that rdp->qlen is still large?  The disadvantage is that qlen
> > > still counts the number of callbacks that are already slated for
> > > invocation.
> > 
> > This is not easy to do. rcu_start_batch() is "global", we need
> > to scan all per-cpu 'struct rcu_data' and check it's ->qlen.
> 
> My thought was that it might make sense to check only this CPU's struct
> rcu_data.  But I agree that the next approach seems more promising.

Yes, I understood this. And I don't say this is "bad", I just think this is
"not perfect". Because the CPU which actually starts a new grace period and
clears ->signaled may have ->qlen == 0, and the caller is cpu_quiet(), which
is a "response" to some other CPU's force_quiescent_state().

Oleg.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/