Return to BSD News archive
Xref: sserve comp.os.386bsd.questions:6571 comp.os.386bsd.bugs:1730 comp.os.386bsd.misc:1395
Newsgroups: comp.os.386bsd.questions,comp.os.386bsd.bugs,comp.os.386bsd.misc
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!convex!convex!darwin.sura.net!europa.eng.gtefsd.com!uunet!psgrain!agora!davidg
From: davidg@agora.rain.com (David Greenman)
Subject: Re: [FreeBSD-1.0R] Epsilon -> Release patches - problems
Message-ID: <CG4KKn.DBB@agora.rain.com>
Organization: Open Communications Forum
Date: Sun, 7 Nov 1993 14:07:33 GMT
Lines: 66
> Disk performance seems to be up a bit - the dynamic buffer cache is
> very noticeable for small files (under 8M) - at least this is what
> I found with iozone.
>
>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!
The problem that people are having is the definition of the word
"dynamic". So what does it currently mean in the case of FreeBSD?
Here is an excerpt from an explaination I recently sent to the
FreeBSD-hackers mailing list:
----
>4. The size of the buffer cache never grows or shrinks after this, since
> we're just passing blocks back and forth between clean and dirty lists,
> adding and deleting items from the hash table.
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. It didn't use to be this
way...the malloc code was modified to return page-sized allocations back to
the main memory pool.
----
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.
The mechanism that we have with FreeBSD's malloc and buffer cache code
can certainly be improved, but what made it out in 1.0 is a good start.
> Now for some YP and shlibs ...... ;-)
>
>NetBSD 0.9 has YP, and NetBSD-current has SunOS-like shared
>libraries. Aren't you guys working on incorporating our code?
This is sure a strange way to put it. First, as I'm sure you know
because you watch changes in FreeBSD like a hawk, the shared library
code has been put into our tree almost simultaneously with the work
that is going on in NetBSD. The people that have been working on this
stuff contribute to both NetBSD and FreeBSD, and I'm sure consider
this work "theirs" *not* NetBSD's or FreeBSD's.
>(sun-lamp has only been using shared libraries for ~a week, but in all
>respects they seem quite reliable.)
"seem quite stable" is not exactly the criteria I would use to switch
a development machine over to code that is still undergoing completion.
But, whatever, I don't care what you guys do. The approach that we've
decided to take is to have a handfull of beta testers for the shared
libraries, and when things look truely stable, will expand the use
to include freefall (our development machine).
One last thing. The tone of this isn't going to persuade folks to
use one system or the other. It will serve only to alienate people
into deciding not to use _any_ of this stuff. I'm sure a lot of people
would rather use *DOS* than have to live with this kind of petty
bickering. If you are truely interested in promoting your "product",
then do it by accentuating the positives - not by trashing the
"competitors" "product". It will make all of our lives a lot better.
-DG