Re: rib_trie / Fix inflate_threshold_root. Now=15 size=11 bits

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Fri, Jun 26, 2009 at 06:45:57PM +0200, Jarek Poplawski wrote:
> On Fri, Jun 26, 2009 at 09:23:40AM -0700, Paul E. McKenney wrote:
> > On Fri, Jun 26, 2009 at 06:15:00PM +0200, Jarek Poplawski wrote:
> > > On Fri, Jun 26, 2009 at 05:54:10PM +0200, Jarek Poplawski wrote:
> > > > On Fri, Jun 26, 2009 at 08:30:10AM -0700, Paul E. McKenney wrote:
> > > > > On Fri, Jun 26, 2009 at 05:10:52PM +0200, Jarek Poplawski wrote:
> > > > > > On Fri, Jun 26, 2009 at 03:52:55PM +0200, Robert Olsson wrote:
> > > > > > > 
> > > > > > > Jarek Poplawski writes:
> > > > > > > 
> > > > > > >  Thanks, 
> > > > > > > 
> > > > > > >  Should be worth testing so we synchronize_rcu instead of doing call_rcu's
> > > > > > >  
> > > > > > 
> > > > > > Alas take 2 (nor 1) doesn't compile, so here it is again.
> > > > > 
> > > > > So the idea is to balance memory and latency, so that large changes
> > > > > (those affecting the root node) get at least one synchronize_rcu(),
> > > > > while smaller changes just use call_rcu(), correct?  This means that
> > > > > the amount of memory awaiting an RCU grace period is limited, but
> > > > > the algorithm avoids per-node synchronize_rcu() overhead.
> > > > > 
> > > > > If I understand the goal correctly, looks good!  (Give or take my
> > > > > limited understanding of fib_trie and is usage, of course.)
> > > > 
> > > > The goal is practically to replace all call_rcu() during
> > > > trie_rebalance() with synchronize_rcu() (except some freeing after
> > > > ENOMEM). I guess currently (<= 2.6.30) call_rcu() can free this
> > > > memory after trie_rebalance() has finished, that's why there were
> > > > problems with enabled preemption. So this patch tries to do/force
> > > > this a bit earlier - at least before the top/largest node is
> > > > rebalanced.
> > > 
> > > On the other hand, we could probably stay with call_rcu() plus only
> > > one synchronize_rcu() before the top node's resize() if you think it's
> > > enough here?
> > 
> > Well, my first task is to understand the problem/goal.  ;-)
> > 
> > My guess from what you said above is that use of call_rcu(), when
> > combined with changes to the trie in rapid succession, is resulting
> > in excessive memory awaiting a grace period.  Is this the case, or am I
> > confused?
> 
> Exactly! (I guess... ;-)

;-)

In that case, simply invoking synchronize_rcu() every once and awhile
should take care of things.  This could be at the end of every large
trie operation, or you could even count the call_rcu() invocations and
do a synchronize_rcu() every 100th, 1,000th, or whatever, based on
the amount of memory available.

							Thanx, Paul