Return to BSD News archive
Xref: sserve comp.os.386bsd.questions:6576 comp.os.386bsd.bugs:1733 comp.os.386bsd.misc:1397
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!usenet.ins.cwru.edu!eff!news.kei.com!bloom-beacon.mit.edu!ai-lab!life.ai.mit.edu!mycroft
From: mycroft@duality.gnu.ai.mit.edu (Charles Hannum)
Newsgroups: comp.os.386bsd.questions,comp.os.386bsd.bugs,comp.os.386bsd.misc
Subject: Re: [FreeBSD-1.0R] Epsilon -> Release patches - problems
Date: 07 Nov 1993 20:08:10 GMT
Organization: MIT Artificial Intelligence Lab
Lines: 58
Message-ID: <MYCROFT.93Nov7150811@duality.gnu.ai.mit.edu>
References: <CG4KKn.DBB@agora.rain.com>
NNTP-Posting-Host: duality.ai.mit.edu
In-reply-to: davidg@agora.rain.com's message of Sun, 7 Nov 1993 14:07:33 GMT
In article <CG4KKn.DBB@agora.rain.com> davidg@agora.rain.com (David
Greenman) writes:
>
>The vfs__bio.c in FreeBSD 1.0 {greek letter,release} is still the same
>one from 386BSD, and does *not* give memory back to the rest of the
>system after it is allocated. The release announcement was seriously
>incorrect. I suggest you read the code.
I suggest *you* read the code, Charles, as your statement is wrong!
No, it is not. I have read the code several times, and it does *not*
do what has been advertised previously, Dave.
The problem that people are having is the definition of the word
"dynamic".
No, the problem is you're using it in a context where it is hardly
appropriate.
Not exactly true. The cache often is used to buffer fragments and
partial reads (like directories, and perhaps other things like
inodes). These are usually 1k fragments, and will supplant the 4/8k
buffers. When this happens, the memory that is allocated to the
cache is freed to the main memory pool and can be used by other
processes/things on the system.
(I've taken a bit of liberty with the use of `page' below, but the
meaning is clear.)
i.e. When a buffer is reduced to N fragments in size, the memory
allocation is shuffled around, fragmenting the address space and
causing the page it's in to not be usable for a larger buffer until
the previous buffer is freed again. If enough fragmentation occurs,
you will eventually not be able to allocate any large buffers. It is
conceivable that in the particular example of UFS fragments it may
only under very rare circumstances become fragmented enough to be
noticable, but in the case of mixing 4k and 8k file systems, it almost
certainly will cause problems.
The above paragraph is assuming that you allocate more buffer headers
than pages; if not, then it hardly matters, because you could just
assign a page to each buffer header statically.
Now, this is actually quite important because, unlike the FS cache
in NetBSD, buffer space isn't wasted. If your cached block is 1k,
then it consumes just 1k of memory.
Multiplied by a monotonically increasing factor for the fragmentation
mentioned above.
And for the record, I have *never* said that NetBSD's current buffer
cache is the penultimate; clearly a truly dynamic mechanism is
better. I am, however, taking exception to the unfounded claim that
FreeBSD's is dynamic.