From: butler@cs.tulane.edu (Larry Butler) Subject: Re: .97 (new buffer allocation code) Date: Mon, 3 Aug 1992 03:56:48 GMT
In article <Aug.2.15.30.57.1992.27385@dumas.rutgers.edu> hedrick@dumas.rutgers.edu (Charles Hedrick) writes:
>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.
I have a 386DX/40 with 8MB and I've noticed the slow down (but oly when I am
running X).
Larry