> 
> Of course out *I* didn't read Jukka's post carefully enough at first,
> either: the problem is in the XFree86 Xserver on NetBSD, not in the
> ApplixWare client at all.  But still, I haven't (yet) suggested that
> NetBSD use AVL trees.
> 
> How do you feel when when people misquote or misrepresent what you write?
> 
Please specify the context with which you are referring to.

>
> And if you missed the emulation-mode context (Jukka Marin has brought
> this up, before, as a LInux-emulation problem), there's there's some
> similar FreeBSD-specific context about AVL trees here -- sorry, but I
> had absolutely no idea.
> 
I really don't understand the tone of this statement.  I am offering some
insight as to why there might be a problem for those who might want to work on
the problem in NetBSD.  It would be unfortunate if someone started working
on solving the problem using a method unnecessarily complicated, and
perhaps slower.

> 
> >FreeBSD has some improvements in this area, but there
> >are still uncommon pathelogical cases where the VM map can get fragmented.
> >There are several VM scalability issues that make the system slow down
> >under various conditions.   The pmap (at least on the X86) from the
> >original BSD VM code has some problems with scalability also.  Significant
> >pmap restructuring is needed to improve that situation.  (Micro level
> >improvements like simple code optimizations don't address the problems.)
> 
> Umm, yes, I know, that's why I suggested this as a potential cause,
> when I saw Jukka's mmap() trace.  (And why I thought the _comparison_
> to AVL trees was apropos.)
> 
The issue of the lack of proper *coalesing* code in the original Net/2 and
later VM code was not mentioned.  The AVL tree approach is
another, more sophisticated solution to the problem.  I was just
trying to state for those who might not know, that specific "solution"
might be overkill.  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.)

> 
> The FreeBSD VM system is really pretty good, and I really do
> appreciate suggestions and observations from someone who's worked on
> the BSD VM code.  (Your fix for the paging problem in NetBSD 1.2 was
> spot-on, once you actually beleived to what I told you about the
> paging and the audible 1Hz disk-write behaviour :)).
>
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.

> And I don't pretend to know as much about the BSD VM system (either
> before your rewrite or after) as you, and the performance numbers from
> after look very competitive.  But some of the rest of us have
> implemented and tuned VM systems, and have some clue also.
> 
Please recognize that I have not been attempting to be offensive.

>
> You haven't lived until you've TeXed large documents using a four-page
> resident set :).
> 
EEEK!!!  Why do that???? :-).

John