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:

quoted

On Fri, Jun 26, 2009 at 06:15:00PM +0200, Jarek Poplawski wrote:

quoted

On Fri, Jun 26, 2009 at 05:54:10PM +0200, Jarek Poplawski wrote:

quoted

On Fri, Jun 26, 2009 at 08:30:10AM -0700, Paul E. McKenney wrote:

quoted

On Fri, Jun 26, 2009 at 05:10:52PM +0200, Jarek Poplawski wrote:

quoted

On Fri, Jun 26, 2009 at 03:52:55PM +0200, Robert Olsson wrote:

quoted

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