netdev - Re: rib_trie / Fix inflate_threshold

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 26 Jun 2009 09:37:27 +0000
From:	Jarek Poplawski <jarkao2@...il.com>
To:	Robert Olsson <robert@...ur.slu.se>
Cc:	Eric Dumazet <dada1@...mosbay.com>,
	=?ISO-8859-2?Q?Pawe=B3_Staszewski?= 
	<pstaszewski@...are.pl>, Robert Olsson <robert.olsson@....uu.se>,
	Linux Network Development list <netdev@...r.kernel.org>
Subject: Re: rib_trie / Fix inflate_threshold_root. Now=15 size=11 bits

On Fri, Jun 26, 2009 at 11:19:07AM +0200, Robert Olsson wrote:
> 
> Jarek Poplawski writes:
> 
>  > >> oprofile: using NMI interrupt.
>  > >> Fix inflate_threshold_root. Now=15 size=11 bits
>  > >> Fix inflate_threshold_root. Now=15 size=11 bits
>  > >> Fix inflate_threshold_root. Now=15 size=11 bits
>  > >> Fix inflate_threshold_root. Now=15 size=11 bits
>  > >> Fix inflate_threshold_root. Now=15 size=11 bits
>  > >> Fix inflate_threshold_root. Now=15 size=11 bits
> 
>  > On the other hand, even if there is no problem with memory, it seems
>  > because of hitting max_resize the threshold should be changed, e.g.
>  > by reverting the patch below.
> 
>  You seem to have some temporary memory problem. So the printout might be
>  a bit misleading in this case. We really like to keep the root node as big 
>  as we can to keep the tree as flat as possible for performance reasons.
>  (We're even more motivated now when we can disable the route cache)
> 
>  So I'll guess the next insert/delete inflates the root node to be within
>  the interval. So I'll assume this just a temporary failure?
> 
>  I would be nice to have *threshholds* settable by /proc or /sys. I would
>  use this in the other direction to trade memory for even faster lookups. 
>  
>  But maybe experts memory allocation has some good suggestions.
> 

Pawel has reported these problems for a long time:
http://bugzilla.kernel.org/show_bug.cgi?id=6648

So, until it's fully investigated, it seems some 'fast' fix is needed
here.

Cheers,
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