From: hedrick@dumas.rutgers.edu (Charles Hedrick) Subject: Re: .97 (new buffer allocation code) Date: 2 Aug 1992 19:30:57 GMT
danielce@mullian.ee.mu.OZ.AU (Daniel AMP Carosone) writes:
>But, there *is* a problem. The whole system is *much* slower. Screen
>updates come in chunks of a half-dozen lines at at time, and emacs
>takes *ages* to load -- some times it's even aborted, saying `Alarm
>Clock'. I'm not game to go near gcc like this.
I'll bet the problem is the new buffer code. It allocates file system
buffers dynamically. It also deletes them dynamically. This means
that the actual number of buffers depends upon the long-term balance
between the creation and destruction process. I'm willing to bet that
on a 3MB machine, you end up with more buffers than before. This
would slow things down, because it would force you into paging. I
suspect that there should be a kernel parameter that limits the number
of buffers allocated, which is set fairly low on small machines.
Either that, or the balance between creation and destruction needs to
be altered so that high paging rates destroy buffers.
I think this is the same thing that happened to SunOS in version 4.0.
They moved from a fixed set of buffers to code that would allow any
page in memory to be used for either programs or files. This produced
a significant improvement for large systems, but it was a problem for
smaller ones. I think people who looked into tuning concluded that
there should be limits on how much memory would get used for each
purpose.