lkml.org 
[lkml]   [1998]   [Aug]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.1.xxx makes Electric Fence 22x slower

On Mon, 24 Aug 1998, Stephen C. Tweedie wrote:

> > Elapsed time in seconds 2.0.34 2.1.117
> > ----------------------- ------ -------
> > Without Electric Fence 3.82 3.72
> > With Electric Fence 14.61 325.85 (!)
>
> Back when the AVL vma tree was removed from 2.1, this same complaint was
> made. I can't remember who, but somebody replied that yes, this was a
> known problem, but there was new code planned to replace the AVL code to
> restore the performance when we have large numbers of vmas.
>
> Obviously, we have not done so. Are there any plans in this direction,
> or do I have to replace the AVL code? I'm perfectly willing to go to
> the extra effort of special casing the code so we only drop from linked
> list to AVL tree when we exceed a certain threshold of vmas in a mm, to
> keep the good simple-case performance we have now, but we _need_
> something better than O(n) for vma lookup and insert/delete.

'switching' an algorithm makes things very complex and hard to debug.

[For similar reasons, leading european soccer teams implemented 'one
strategy no matter wether they are loosing or winning' in the early 90s.
Earlier, every team had a separate strategy for both scenarios, and this
created confusion and lack of focus amongst footballers when they got a
goal that 'switched' the strategy. Such confusion and lack of focus
typically resulted in more goals to their disadvantage. Although Linux
hackers usually have higher IQ than football players, we preferably want
to have a 'single focus' too.]

AFAIK David has some very cool single-strategy scheme for this whole vma
problem.

-- mingo


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.102 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site