On Tue, Mar 17, 1998 at 12:33:36PM -0500, Chad Mynhier wrote:
> As a by-product of some (unrelated) research, I'm seeing something
> similar to what Jukka Marin described in some messages to port-i386 
> early this year (early February, if you go back to the archives.)

Thanks for running the tests! :-)

> I ran this test using both 1.3 and -current UVM kernels.  I also ran the
> test on a P-166 Linux machine, although I did it only long enough to be 
> fairly certain that the times were reaonably constant.

I already thought linux didn't have this problem (if it did, the Applixware
users on linux would definately be whining).  Your findings confirm my
guess.

> One possible explanation for the NetBSD X server slowdown is that somewhere
> a linked list is constantly growing, and that every new window requires a
> traversal of that list.  It was proposed by Jonathan Stone that it could be
> a side-effect of the linked-list representation of a process' address space 
> in the NetBSD VM code [port-i386.0467].  Chuck Cranor [port-i386.0468]
> said that the UVM code still has the linked list and suggested using ddb to
> track the number of entries in the list as the X server gets slow.

After monitoring the list size on my system, I don't think it's the list
size alone that causes the slowdown.  I would think there should be
something like thousands of nodes in the list to make such a big difference
in speed.

> 		1.3 kernel			UVM kernel
> Run	List size	Time		List size	Time
> 0	42		3.80		30		3.82
...
> 160	45		8.49		32		8.21


It's clear that adding two nodes to the list can't make the overhead
over 100% larger..

> I have also not built an X server with XFree's InternalMalloc disabled.

It would be interesting to know if this has any effect on the problem.
I run XFree with InternalMalloc disabled now (because I have to use
Applixware and I can't wait 20 seconds for every screen update) and
things run fast enough for me - but the X server process slowly grows
until it hits the datasize limit and I have to restart it (I had the limit
set to 49 MB, but that wasn't enough, so it's not set to 64 MB - yikes).

I hope we can get this problem tracked down and solved, finally.. ;-)

  -jm