lists.openwall.net   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  linux-hardening  linux-cve-announce  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:	Fri, 3 Jul 2009 00:13:29 +0200
From:	Jarek Poplawski <jarkao2@...il.com>
To:	Robert Olsson <robert@...julf.net>
Cc:	Paweł Staszewski <pstaszewski@...are.pl>,
	Linux Network Development list <netdev@...r.kernel.org>,
	Robert Olsson <Robert.Olsson@...a.slu.se>
Subject: Re: [PATCH net-2.6] Re: rib_trie / Fix inflate_threshold_root.
	Now=15 size=11 bits

On Thu, Jul 02, 2009 at 11:32:26PM +0200, Robert Olsson wrote:
> 
> 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.

I can't remember this script, but I guess my hardware should be
suitable for reading it.;-)

> 
>  > >  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.

I mean changing thresholds as a temporary solution, until we can
control memory freeing; and it seems to me, even excluding the root
node, there could be a lot of temporary allocations during all those
cycles repeated 10 times.

> 
>  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.

Then it should depend on CONFIG_PREEMPT_NONE, I guess.

>  
>  First week of vacation and have to fix the roof of the house...
>  it's hot and dirty. 

Have a nice time,
Jarek P.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ