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  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]
Date:	Thu, 2 Jul 2009 23:32:26 +0200
From:	Robert Olsson <>
To:	Jarek Poplawski <>
Cc:	Robert Olsson <>,
	PaweĊ‚ Staszewski <>,
	Linux Network Development list <>,
	Robert Olsson <>
Subject: Re: [PATCH net-2.6] Re: rib_trie / Fix inflate_threshold_root.
	Now=15 size=11 bits

Jarek Poplawski writes:

 > >  Controlling RCU seems crucial. Insertion of the full BGP table increased
 > >  from 2 seconds to > 20 min with one synchronize_rcu patches.
 > I wish I knew this a few days before. I could imagine a slow down,
 > but it looked like it was stuck. Since these last changes weren't
 > tested on SMP + PREEMPT I thought there is still something broken.
 > (I was mainly interested in this synchronize_rcu at the moment as
 > a preemption test.)  

 Honestly this huge slowdown was surprise for me too. I think I sent 
 you a script so you could insert the full table yourself.

 > >  And fib_trie "worst case" wrt memory is the root node. So maybe we should 
 > >  monitor changes in root node and use this to control synchronize_rcu.
 > > 
 > >  Didn't Paul suggest something like this?
 > Sure, and it needs testing, but we should send some safe preemption
 > fix for -stable first, don't we?
 Yes my hope was that we could combine them... personally I'll need 
 to understand who we can preeemted better in the different configs
 and most of that this can be handled by "standard" RCU.

 > >  And with don't find any decent solution we have to add an option for 
 > >  a fixed and pre-allocated root-nod typically for BGP-routers.
 > Probably you're right; I'd prefer to see the test results showing
 > a difference vs. simply less aggressive root thresholds. But of
 > course, even if not convinced, I'll respect your choice as the author
 > and maintainer, so feel free to NAK my proposals - I won't get it
 > personally.;-)

 Thresholds we can change no problem... but very soon I'll people 
 will start routing without the route cache this at least in close
 to Internet core ,we will need all fib_look performance we can get.

 fib_trie was designed for classical RCU and no preempt you see the
 names i file... so this new and very challenging work to all of us.
 First week of vacation and have to fix the roof of the house...
 it's hot and dirty. 

To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists