Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!sol.ctr.columbia.edu!hamblin.math.byu.edu!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: 386BSD or LINUX?
Message-ID: <1992Nov5.185438.29465@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <1992Nov4.205620.8184@colorado.edu> <1992Nov5.060658.639@ntuix.ntu.ac.sg>
Date: Thu, 5 Nov 92 18:54:38 GMT
Lines: 147
In article <1992Nov5.060658.639@ntuix.ntu.ac.sg> eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) writes:
>Drew Eckhardt (drew@kinglear.cs.colorado.edu) wrote:
>:
>: Linux +'s :
>:
>: Shared libraries. This results in a significant disk space savings,
>: especially in the case of 'X' applications that can shrink by
>: an order of magnitude when compiled with shared libraries.
In all fairness, there are those of us who have shared libraries "working"
on 386BSD using the AT&T 3B1 (UNIX PC)/Linux model, but are dissatisfied
enough with the paradigm to never release the code since it would result
in an effectively permanent limitation on program size that would keep us
from running things like Postgress, NetWare for UNIX, FrameMaker, or other
large commercial or commercial quality applications. There is also the
problem of arbitrating entry point address ranges, and intrinsic size
limits on items in a particular library (ie: libc can only get so big).
Those of us with the gcc 2.3.1 compiler can also see how much easier it
is to impliment "real" (Sun/AIX style) shared libraries.
>: Modern VM, with a unified buffer cache and user memory pool.
>
> I never believe in VM. Once we do not have enough RAM, might as well buy
>more RAM.
> Unified buffer cache? How much can we gain? CAn you tell us more
>about its algorithm, especially how it decides to choose which is to give
>priority to, and how it handles the paged user memory?
Again, to be fair, a unified buffer cache is a significant advantage, in
my opinion, since it allows swapping to files, among other things, with
little effort (the VFS interface already supports linear block allocation
with the VOP_ALLOCSTORE() operation, the major argument against swapping
to files being the potential hassle of seeking all over the place). In
addition to this, a unified cache (assuming swap paged have priority)
gives a built-in backoff hueristic to insure that context switches will
occur, even under heavy system loading. It also has the effect of reducing
other disk I/O when the system is "swapper-bound", which provides a
"scaling for hardware capability" effect. The only control BSD has over
this is the configuration of system buffers as a percentage of main
memory, insufficient, in my opinion.
The "moden" VM, I'm assuming, is a reference to the fact that BSD has
classically required as much swap space as there was virtual plus real
memory, whereas System V VM has only required as much as there was virtual
memory.
In theory, the BSD system is better because paging non-modifiable pages off
of disk from the original files is slower than getting them from a unified
swap partition. It is more expensive in terms of the size of main memory
worth of disk space is "wasted". This actually should be a configuration
option. When the size of main memory exceeds the size of swap on a BSD
system is when your machine crashes from running out of memory without giving
an "insufficient memory" message instead.
>: Many kernel structures, such as pty's, are dynamically allocated. This
>: increases the amount of pageable memory that is available.
This is the AIX approach; where you get into trouble with this is when you
"run out". On AIX, this usually occurs when a copy-on-write page is
written to, and there is insufficient memory for the copy to complete. BSD
protects you from this by requiring enough virtual+real memory for all
images. AIX simply terminates the largest image ungracefully. I don't
know what Linux does in this case, but I suspect it either does what AIX
does or keeps a "page reserve" to know that it has enough memory for all
processes currently in core so it can't run out.
The idea of paging from executables generally results in a slower run-time
(on systems doing swapping) because the text pages for an executable are
not necessarily in contiguous disk blocks; however, it *appears* more
responsive because of it's ability to begin executing after loading a single
page.
As to kernel configuration, I believe we can learn a lot from SVR4 and Linux
(although recompilation of every space.c per kernel rebuild seems like a waste
to me, and I would be more sympathetic to a change that assembles files.i386
from pieces to allow us to implement "drop in" drivers.
>How do we change its number? CAn we add pty indefinitely?
Actually, this is a simple change involving a cloning pty driver, even on
BSD.
>: More "odd" hardware is supported in the stock distribution. For
>: instance, SCSI support is there for Seagate, WD7000, Future Domain,
>: Ultrastor 14f, and Adaptec boards.
This, I truly envy.
>: There are more WhizzyFeatures (tm), such as /proc.
This is easy to write for 386BSD using VFS. The fact that the current
VFS allows the propagation of ioctl()'s through the syscall layer helps
a *lot* here. I actually wrote a simple /proc VFS for 0.0.
>: Linux supports the MSDOS file system, and can run vm86 tasks such
>: as the DOS emulator, if you consider these +'s.
>
>Where is the source for this DOS emulator?
I would think a DOS emulator would be simply be an initialization state
for the virtual 8086. Mostly, it would be mapping the ROMs and maintaining
the pre Linux (or 386BSD) boot state information. This might require the
use of 8086 ROM images, as in DOS/Merge or Merge/386. The support for the
DOS fs is arguably easy. There are several 386BSD with working alpha code
for this. I have one myself; I'd prefer to get the boot reset translation
problems out of the way so that the DOS partition table meant something to
the mount before releasing it.
>: I'd say that if you want BSD, because it's BSD, or if you want
>: stable NFS NOW, and not in two weeks, that it might be worthwhile.
>
>Have you forgotten that it has the VFS(?), which is the Posix complient file
>system. Or has linux used it already? What it does is to have long file names,
>faster throughput because of large block sizes(4K),without much fragmentation
>becaue it can go down to 1K block size as well,or am I mistaken?
Linux supports the VFS interface (which is not a very good developement
system; read:
ftp.cs.ucla.edu:/pub/ficus/ucla_csd_910056.ps
which is John Heidemann's master's thesis, available via anonymous FTP
for details).
VFS does not equate automatically with a POSIX file system; UFS as it is
distributes in 386BSD is *mostly* POSIX compliant. All of the UFS features
mentioned are, however, good points in 386BSD's favor.
>How about performance comparisons? I've posted the results of iozone 1 to
>comp.unix.bsd .
I'd be interested in this as well.
Terry Lambert
terry@icarus.weber.edu
terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------