lkml.org 
[lkml]   [2006]   [Sep]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] simplify/improve rcu batch tuning
On Fri, Sep 08, 2006 at 08:30:22PM +0400, Oleg Nesterov wrote:
> On 09/08, Paul E. McKenney wrote:
> > On Fri, Sep 08, 2006 at 03:39:30PM +0400, Oleg Nesterov wrote:
> > > > > @@ -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().

Sounds good!

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

\
 
 \ /
  Last update: 2006-09-08 21:01    [W:0.039 / U:6.440 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site