On Fri, Jun 26, 2009 at 11:21:43AM -0700, Paul E. McKenney wrote:

On Fri, Jun 26, 2009 at 08:05:45PM +0200, Jarek Poplawski wrote:

quoted

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

quoted

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.

OK, for now the minimal change for testing (2.6.30 needs previously
mentioned two commits from 2.6.31-rc). (I guess I'll send it with a
changelog after net-next is opened.)

Looks promising to me!!!

Alas, after rethinking, there is one detail which bothers me. Those
largest allocs here are done with vmalloc and freed with RCU by
schedule_work(). So, I wonder if just because of this, the previous
version doing it directly isn't more reliable anyway. Of course, it's
my bad I didn't point it while describing the problem earlier. (I knew
I missed something...;-)

Thanks,
Jarek P.