> 
> I've pointed out that, in fact, I didn't, I just mentioned that Linux
> did do so, and I've asked you to *not* say I did.  
> 
> And you then you reply:
> 
>   >It would be unfortunate if someone started working
>   >on solving the problem using a method unnecessarily complicated, and
>   >perhaps slower.
> 
> what's ``unecessarily complicated and perhaps slower''? AVL trees,
> (which no-one is proposing at this time except *you*), or something else?
> 
Ahhh... come on...  dont be so sensitive.  I am not accusing.  Note that
the public list that you were talking about is tech-kern...  Hopefully,
it is an open forum of ideas, and not flaming...

> 
>   > The map coalese problem is not simple to solve
>   >due to the detailed conditional code needed.  It isn't brain surgery
>   >though.  To solve that specific case, major code restructuring is 
>   >not needed (and FreeBSD has that problem fixed w/o AVL trees.)
> 
> you just aggravate things. John, are you deliberately trying to start
> a flamewar?
> 
Nope...  Sorry, you misunderstand.  We have spent alot of time on
the VM code.  Note that Linux has fixed the problem (actually has
fixed it longer than FreeBSD) one way, and FreeBSD has fixed it
another.  IMO, the AVL approach is not needed.  It doesn't mean
that the AVL approach is *wrong*, it is just mostly not needed.

> 
>   >Please recognize that I have not been attempting to be offensive.
> 
> OK, granted, but please recognize that when you contine to
> misunderstand and/or misrespresent what I said, even after I've asked
> you not to, that's not at all how it seems.
>
I have not been representing what you have said.  You brought up an
idea that Linux uses AVL trees which implies that it might solve the
problem, and I replied that it isn't necessary to use the AVL trees.
I additionally stated that the missing coalese code is partly 
at fault.  So to those looking at the code, they can see that
the code is missing, and fixing that problem is a start to
mitigating the map fragmentation issues.

Rather than redesigning the map management code with using an AVL
structure, the problem that is being alluded to can likely be resolved
(or at least improved) by "completing" the existing code.

> 
> >Note that my suggested mod was NOT a fix, but only a work around.  A
> >fix requires much more work.  Note that much of the problem is mitigated,
> >but a more complete solution would be desirable.
> 
> I think we're not talking quite the same language, then.
> To you, the word "fix" has connotations it doesn't to most people.
> I used "fix" in the sense of a ``simple quick fix'', as contrasted, to,
> say, a redesign and rewrite.  This sense of the word "fix" is well
> understood by most other people; it's used in the NetBSD CVS logs for
> similar "fix"es to other VM system problems.
> 
In my parlance, if someone fixes a problem, it's effects are not only mitigated,
but the problem is also fixed.  I thought that most people who use the
term "fix" mean "fix".  At work and on FreeBSD , I have always distinguished
between "fix" and "work-around."

>
> What's do you mean by a ~fix"?  That we use your VM system,
> o something similarly re-designed and re-implemented?
> 
It isn't necessary to re-design the VM system to fix the problem.  Sorry,
I didn't know that "fix" means "work-around" :-).  Usually when I say fix,
I mean fix :-).  I use "work-around" as a nonprejudicial, nice form of "reasonably
well thought out hack."  -- at least when it comes to my code, or my suggestions.
Simply, I didn't want people misinformed that I endorsed the the modification
to NetBSD as a "fix."

John