From: metcalf@CATFISH.LCS.MIT.EDU (Chris Metcalf)
Crossposted-To: comp.os.386bsd.questions,comp.sys.ibm.pc.hardware,
comp.windows.x.i386unix
Subject: SUMMARY: 486DX2/66 for Unix conclusions (fairly long)
Date: 9 Jul 1993 17:13:39 GMT
I've made several posts over the last month or two asking for help in
buying a 486 PC system. Here is a summary of the recommendations I
received; it is crossposted to the four newsgroups I asked for help and
information on.
The criteria I wanted to meet were:
1 Workstation-class integer performance.
2 Runs a free Unix with source code
3 Reasonable X performance under a mainly text workload
4 Price as low as possible ($2500 or less)
Point 1 (performance) obviously pushed me towards the 486DX2/66.
I initially considered the 486DX/50, but a number of people pointed out
that current boards and busses seem to be running better at 33 MHz, and
that the faster cycle speed of the DX2/66 overwhelmed its potentially
lower memory and bus bandwidth in most if not all things. I also made
sure that the motherboard I bought was socketed for an OverDrive processor
when it becomes available, so I can upgrade in a year or two.
For point 2 (free Unix), the current choices are Linux and 386BSD/NetBSD.
I chose Linux for a number of reasons, some of which may no longer be
true in six months' time:
o Linux uses the disk better: shared libraries for executables, and
virtual memory is physical memory PLUS disk swap partitions;
386BSD currently uses unshared libraries (though apparently
some people are working on this), and does the usual BSD virtual
memory technique where all virtual memory must be backed by swap.
o Possibly even more important, I liked the feel of the Linux
community better. It's less fragmented; Linux kernel and X
releases are packaged in a number of different ways (e.g. SLS),
but which package you run generally doesn't matter that much.
By contrast, 386BSD seems to be marked by infighting among
the pure 386BSD Jolitz crowd, the patch release folks, and
the NetBSD schism; while everyone involved seems very sincere
and well-intentioned, the net result is to make things harder
on the user community. Possibly as a result, the Linux user
community also appears to be larger and faster-growing, which
also points towards Linux as the OS of choice.
o Linux (as a POSIX OS with BSD/SYSV extensions) seems to be an
easier porting target than 386BSD et al (despite the fact
that I have been a BSD user exclusively for eight years...).
o Linux DOS emulation seems to be better developed and evolving.
Linux has some failings (e.g. the networking code is not as robust as
BSD's), but problems seem to be being dealt with rapidly. In fairness, I
expect that I will probably try to bring up BSD on a partition of its own,
and if it gets support for shared libraries and if one of the variants
(e.g. NetBSD) comes out as a clear winner in the user community I might
well switch to it later. Bottom line is you can't go wrong with either.
To handle the demands of a Unix machine running X, people widely recommend
16 meg, with at least 128K of cache. People do claim to run Linux/X with
8 meg satisfactorily, but apparently if you do big gcc compilations on top
of that it starts to bog down. So I opted for the 16 meg configuration;
expandability beyond that is easy, as long as your board supports caching
the higher memory. There's often a choice of 70 ns or 60 ns memory;
you might be able to squeeze one fewer wait states out of 60 ns memory,
but with most motherboards you'd be riding outside the specs for the memory.
Disk space is simple: figure out how much you need, and double it.
I decided to get a 340 meg disk, which seems ridiculously more than
necessary for me today, so it will probably be stuffed full by the end of
the year. Disk prices dropped this month anyway, which was a good excuse.
Don't bother to get a caching controller if you're mainly running Unix,
since Unix does caching in main memory anyway.
You will need to decide if you want to get a SCSI adapter and a SCSI disk;
however, it will definitely be more expensive, since you need a separate
SCSI controller (about $200), and SCSI disks are often more expensive
than IDE disks. Furthermore, it is said that for disks up to 500MB,
SCSI probably won't give you any noticeable performance improvement
unless you are running a heavily used disk server.
Point 3 (X) was the hardest for me to figure out, since there is an
incredible variety of graphics cards and monitors. I decided to go for a
color 15" flat-screen noninterlaced monitor, which is about the smallest
you can get and still run two 80-column pages side by side on the screen.
This may be a false economy; lots of people suggested spending a little
more for a really nice monitor. We shall see how it works after a week
or so. Interestingly, I measured some display-diagonal lengths with a
ruler, and found that a good 15" can be almost as big as a 16" or 17":
15" Mag Innovision 14.3" (what I'll be buying)
16" Sun Trinitron 14.7" (what I use at work)
17" Morse 15.7" (if you want to pay $300 or so more)
Graphics cards are harder. I decided against the higher-priced
graphics cards such as the ATI Ultra Pro or S3-based cards; if I had
been looking for graphics performance, this is what I have bought.
Instead, I bought a Cirrus 5426-based card for $95, which offers
reasonable performance today with XFree86 1.3, and significantly better
performance when XFree86 2.0 is released.
One question I explored was whether I could use a DEC color monitor such
as the VR290 with a VGA card, since we have some spare monitors at work.
The answer was basically: "maybe", if you can cobble together a printed
circuit-board (details on request, forwarded from Mattis Andersson); and
"yes", if you want to shell out about $500 for a much more general-purpose
box from vendors like EXTRA, In-Line Systems, or EISI. I decided to
just buy a new monitor.
Point 4 ($2500 price) managed to work out; here's the breakdown of the system:
486DX2/66 VESA LB with 256K cache $1375
(package includes 3-button mouse, Mitsumi
keyboard, heatsink fan, 1M memory, 3.5"
floppy, 42M HD, cheap 14" monitor and card)
upgrade to 16M 70ns RAM $601
upgrade to 340 meg HD $225
upgrade to Mag Innovision 15" monitor $248
upgrade to Diamond SpeedStar Pro $86
TOTAL $2535
This price doesn't include full DOS 6.0 ($47) or Windows ($40), which are
sometimes unbundlable; it does include 5% Mass. tax.
There are some things you want to make sure to look for on your
motherboard: you may want to check that it will cache >16M of memory,
which can be a problem. If possible, you probably want to get a
write-back cache instead of a write-through cache, as well. For the
serial UART, you should also try to either get a 16550 (not a 16450),
or get the chip socketed so you can upgrade it; it will help your
Unix not to have to take an interrupt for each character transferred.
Also look for a reputable BIOS supplier such as AMI or Phoenix.
The retailer I worked with is PCs for Everyone, 24 Thorndike Street,
Cambridge, MA 02141, (617) 866-0068. I got a slightly better price from
KC Computers (contact kcc@pt.com), and Dee-One, both mailorder companies.
Prices were around $200 higher from some of the larger mailorder outfits
like Gateway, Insight, Ares, or Zenon. Zeos delivered the highest
quote for a similarly-configured system. I would suggest Gateway as the
mailorder company to beat in terms of price, support, stability and user
confidence, based on what I've heard; Insight is good for the user who
needs less hand-holding; I've heard good things about Ares; and Zenon
has gotten some bad press on the net lately. (I'll mention Dell just
to say that they're significantly more expensive, but you will get the
best hardware, good support, and so forth.)
An excellent source of further info for all this is Eric Raymond's
two guides, archived as pc-unix/hardware and pc-unix/software (e.g.,
at rtfm.mit.edu:pub/usenet/news.answers); the most recent version, 16.0,
was posted on 6 July 1993. Many thanks to Eric for making this document
available and keeping it updated.
And many thanks to the dozens of people who sent me email with various
suggestions about different aspects of the PC buying game!
--
Chris Metcalf, MIT Laboratory for Computer Science
metcalf@cag.lcs.mit.edu // +1 (617) 253-7766
Crossposted-To: comp.os.386bsd.questions,comp.sys.ibm.pc.hardware,
comp.windows.x.i386unix
From: pcg@aber.ac.uk (Piercarlo Grandi)
Subject: Re: SUMMARY: 486DX2/66 for Unix conclusions (fairly long)
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Date: Sun, 11 Jul 1993 23:32:33 GMT
>>> On 9 Jul 1993 17:13:39 GMT, metcalf@CATFISH.LCS.MIT.EDU (Chris
>>> Metcalf) said:
Chris> o Linux uses the disk better: shared libraries for
Chris> executables, and virtual memory is physical memory PLUS disk
Chris> swap partitions; 386BSD currently uses unshared libraries
Chris> (though apparently some people are working on this), and does
Chris> the usual BSD virtual memory technique where all virtual memory
Chris> must be backed by swap.
On the other hand Linux does no swapping. However the BSD swapper sucks,
but maybe it's better than nothing. However overall I think that the VM
subsystem is better under BSD than Linux, even if I would love for it to
use page fault frequency as policy.
Chris> o Linux DOS emulation seems to be better developed and evolving.
Chris> Linux has some failings (e.g. the networking code is not as
Chris> robust as BSD's), but problems seem to be being dealt with
Chris> rapidly.
The main difference is that the BSd kernel is stable, and BSD 4.4 has
been vastlu cleaned up and made more coherent and more general; the
Linux kernel is not badly written, but its organization is far more
haphazard.
Chris> Disk space is simple: figure out how much you need, and double
Chris> it. I decided to get a 340 meg disk, which seems ridiculously
Chris> more than necessary for me today, so it will probably be stuffed
Chris> full by the end of the year.
Get at least 1GB. The cost per MB on disks >= 1GB is much lower than the
cost per MB for disks with lower capacities. A 1GB costs around $1050
mail order... And it will fill up much sooner than you think. Also, get
a CDROM. This will avoid you a lot of FTP hassle, if nothing else.
Chris> You will need to decide if you want to get a SCSI adapter and a
Chris> SCSI disk; however, it will definitely be more expensive, since
Chris> you need a separate SCSI controller (about $200), and SCSI disks
Chris> are often more expensive than IDE disks. Furthermore, it is said
Chris> that for disks up to 500MB, SCSI probably won't give you any
Chris> noticeable performance improvement unless you are running a
Chris> heavily used disk server.
Terrible mistake. The real benefits of SCSI are improved performance if
you have more than one hard disk drive (much recommended), and that one
controller will also handle tapes, CDROMs, and whatnot. Soon enough you
will want to add a backup device (don't bother with QIC drives, it's a
false economy, the tapes are too expensive, get a DAT for $1050), and a
CDROM. Not having chosen SCSI you will need one or maybe two extra
controllers, taking up another one or two precious ISA bus slots.
Crossposted-To: comp.os.386bsd.questions,comp.windows.x.i386unix
From: ralph@unixhub.SLAC.Stanford.EDU (Ralph Becker-Szendy)
Subject: Re: SUMMARY: 486DX2/66 for Unix conclusions (fairly long)
Date: Mon, 12 Jul 1993 00:17:49 GMT
In article <PCG.93Jul12003233@decb.aber.ac.uk> pcg@aber.ac.uk
(Piercarlo Grandi) writes:
>On the other hand Linux does no swapping.
Nonsense. See man swapon, man swapoff, and man mkswap on any Linux
system. I was trying to run X with 4MB for a while, so I can testify
that Linux can swap a hell of a lot if needed :-)
>Get at least 1GB. The cost per MB on disks >= 1GB is much lower than the
>cost per MB for disks with lower capacities. A 1GB costs around $1050
>mail order...
Not completely true. I have seen 200MB for <<$300 recently. So
the figure of $1/MB is not GREATLY exceeded by smaller disks. And compared
to the cost of the rest of a system, $1K for disk is quite high. One
can live happily with 200 or 300 MB, if one is so inclined, and invest
the money into a really good monitor (or a laser-printer), which may
be much more useful.
>And it will fill up much sooner than you think.
That, sadly, is true.
> Not having chosen SCSI you will need one or maybe two extra
>controllers, taking up another one or two precious ISA bus slots.
Why are ISA slots so precious? What do you intend to fill them
with without first running out of IRQ lines? BTW, I am not
disagreeing that SCSI is the better way to go.
--
Ralph Becker-Szendy RALPH@SLAC.STANFORD.EDU
Stanford Linear Accelerator Center RALPH@SLACVM.BITNET
M.S. 95, P.O. Box 4349, Stanford, CA 94309 (415)926-2701
My opinion. This is not SLAC, Stanford U, or the US DoE speaking. Just me.
From: mdw@TC.Cornell.EDU (Matt Welsh)
Crossposted-To: comp.os.386bsd.questions,comp.windows.x.i386unix
Subject: Re: SUMMARY: 486DX2/66 for Unix conclusions (fairly long)
Date: 11 Jul 1993 21:38:30 -0400
In article <CA0zHp.CqK@unixhub.slac.stanford.edu>
ralph@unixhub.SLAC.Stanford.EDU (Ralph Becker-Szendy) writes:
>In article <PCG.93Jul12003233@decb.aber.ac.uk> pcg@aber.ac.uk
>(Piercarlo Grandi) writes:
>>On the other hand Linux does no swapping.
>>
>Nonsense. See man swapon, man swapoff, and man mkswap on any Linux
>system. I was trying to run X with 4MB for a while, so I can testify
>that Linux can swap a hell of a lot if needed :-)
Someone correct me if I'm wrong, but Linux "swapping" is really "paging" to
the hard drive. As far as I know images are not "swapped" to disk or
rendered inactive; the "swap space" is actually used as "paging space".
Therefore, calling it "swap" is probably a misnomer.
If something has changed, someone please bonk me on the head with a
large mallot. Thank you.
mdw
--
Matt Welsh, mdw@tc.cornell.edu
Radioactive decay ain't what it used to be.
Crossposted-To: comp.os.386bsd.questions,comp.sys.ibm.pc.hardware,
comp.windows.x.i386unix
From: pcg@aber.ac.uk (Piercarlo Grandi)
Subject: Re: SUMMARY: 486DX2/66 for Unix conclusions (fairly long)
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Date: Sun, 11 Jul 1993 23:32:33 GMT
>>> On 9 Jul 1993 17:13:39 GMT, metcalf@CATFISH.LCS.MIT.EDU (Chris
>>> Metcalf) said:
Chris> o Linux uses the disk better: shared libraries for
Chris> executables, and virtual memory is physical memory PLUS disk
Chris> swap partitions; 386BSD currently uses unshared libraries
Chris> (though apparently some people are working on this), and does
Chris> the usual BSD virtual memory technique where all virtual memory
Chris> must be backed by swap.
On the other hand Linux does no swapping. However the BSD swapper sucks,
but maybe it's better than nothing. However overall I think that the VM
subsystem is better under BSD than Linux, even if I would love for it to
use page fault frequency as policy.
Chris> o Linux DOS emulation seems to be better developed and evolving.
Chris> Linux has some failings (e.g. the networking code is not as
Chris> robust as BSD's), but problems seem to be being dealt with
Chris> rapidly.
The main difference is that the BSd kernel is stable, and BSD 4.4 has
been vastlu cleaned up and made more coherent and more general; the
Linux kernel is not badly written, but its organization is far more
haphazard.
Chris> Disk space is simple: figure out how much you need, and double
Chris> it. I decided to get a 340 meg disk, which seems ridiculously
Chris> more than necessary for me today, so it will probably be stuffed
Chris> full by the end of the year.
Get at least 1GB. The cost per MB on disks >= 1GB is much lower than the
cost per MB for disks with lower capacities. A 1GB costs around $1050
mail order... And it will fill up much sooner than you think. Also, get
a CDROM. This will avoid you a lot of FTP hassle, if nothing else.
Chris> You will need to decide if you want to get a SCSI adapter and a
Chris> SCSI disk; however, it will definitely be more expensive, since
Chris> you need a separate SCSI controller (about $200), and SCSI disks
Chris> are often more expensive than IDE disks. Furthermore, it is said
Chris> that for disks up to 500MB, SCSI probably won't give you any
Chris> noticeable performance improvement unless you are running a
Chris> heavily used disk server.
Terrible mistake. The real benefits of SCSI are improved performance if
you have more than one hard disk drive (much recommended), and that one
controller will also handle tapes, CDROMs, and whatnot. Soon enough you
will want to add a backup device (don't bother with QIC drives, it's a
false economy, the tapes are too expensive, get a DAT for $1050), and a
CDROM. Not having chosen SCSI you will need one or maybe two extra
controllers, taking up another one or two precious ISA bus slots.
From: metcalf@CATFISH.LCS.MIT.EDU (Chris Metcalf)
Crossposted-To: comp.os.386bsd.questions,comp.sys.ibm.pc.hardware,
comp.windows.x.i386unix
Subject: Re: SUMMARY: 486DX2/66 for Unix conclusions (fairly long)
Date: 12 Jul 1993 01:54:28 GMT
I've set followups on this thread to the OS groups only.
In article <PCG.93Jul12003233@decb.aber.ac.uk> pcg@aber.ac.uk
(Piercarlo Grandi) writes:
>The main difference is that the BSd kernel is stable, and BSD 4.4 has
>been vastlu cleaned up and made more coherent and more general; the
>Linux kernel is not badly written, but its organization is far more
>haphazard.
I'm not convinced there's much difference in stability; I've heard many
people say their Linux systems stay up many months at a time. As for
architectural elegance, my impression is that this is not something that
Linus was initially shooting for---but perhaps something that will grow
as, e.g., 680x0 ports start to work and architecture-independent code is
separated out cleanly, or if the proposed post-1.0 C++ reorganization
starts to get underway. By contrast, 386BSD seems to have gone the
opposite direction, with lots of grim architecture-dependent hacks in
it, and NetBSD trying to pull back the other way.
You pays yer money, and you takes yer choice.
Other people have addressed your remarks about Linux having no swap,
and about the wonderfully cheap price of 340M disks these days; I
am using this workstation as a sort of offline research instrument,
so a small local disk for "caching" my at-work data is what I need.
The last point to address is SCSI. I did consider this for a while, but
today (this year, nor probably next year) I just don't need a CRROM or a
backup device; if I did, I would have paid up for SCSI. Unsurprisingly,
we only use SCSI peripherals at work, so that's what I am prone to use.
But I can keep this IDE drive until I need a full-fledged home machine,
and THEN put out the bucks for a VLB SCSI, a 1GB drive, and so forth.
The old IDE (hanging off a $20 non-VLB controller) will work just fine
for storing my source-code tree or some such at that point, I'm sure.
--
Chris Metcalf, MIT Laboratory for Computer Science
metcalf@cag.lcs.mit.edu // +1 (617) 253-7766
From: davidg@implode.rain.com (David Greenman)
Crossposted-To: comp.os.386bsd.questions,comp.sys.ibm.pc.hardware,
comp.windows.x.i386unix
Subject: Re: SUMMARY: 486DX2/66 for Unix conclusions (fairly long)
Date: 13 Jul 93 11:42:41 GMT
Sorry that I missed the original post, but seeing part of the following
quote, I have to make some corrections to what Chris Metcalf and
Piercarlo Grandi have said:
>Chris> o Linux uses the disk better: shared libraries for
>Chris> executables, and virtual memory is physical memory PLUS disk
>Chris> swap partitions; 386BSD currently uses unshared libraries
>Chris> (though apparently some people are working on this), and does
>Chris> the usual BSD virtual memory technique where all virtual memory
>Chris> must be backed by swap.
It is true that 386BSD as it is shipped does not support have libraries.
It is *not* true that it's total VM must be backed by swap. In fact if
you want you can have *no* swap. The total VM in 386BSD is memory + swap.
386BSD's VM system has nothing in common with original BSD; 386BSD's
VM system is derived from Mach 2.5.
>On the other hand Linux does no swapping. However the BSD swapper sucks,
>but maybe it's better than nothing. However overall I think that the VM
>subsystem is better under BSD than Linux, even if I would love for it to
>use page fault frequency as policy.
This is wrong, too. 386BSD does *not* swap. The swapping code has not yet
been written. 386BSD only pages. This is probably also related to the
fact that 386BSD doesn't use the 'BSD' VM system. As far as performance,
yes, 386BSD does use the extremely simple paging algorithm that was in
original BSD. It would be nice if this was changed to do page reclaimation
based on a per-process working set and page fault frequency, but it
currently doesn't.
-DG
---
David Greenman
davidg@implode.rain.com
Crossposted-To: comp.os.386bsd.questions
From: pcg@aber.ac.uk (Piercarlo Grandi)
Subject: Re: SUMMARY: 486DX2/66 for Unix conclusions (fairly long)
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Date: Tue, 13 Jul 1993 20:19:59 GMT
>>> On 12 Jul 1993 01:54:28 GMT, metcalf@CATFISH.LCS.MIT.EDU (Chris
>>> Metcalf) said:
Chris> I've set followups on this thread to the OS groups only.
Chris> In article <PCG.93Jul12003233@decb.aber.ac.uk> pcg@aber.ac.uk
Chris> (Piercarlo Grandi) writes:
pcg> The main difference is that the BSd kernel is stable, and BSD 4.4
pcg> has been vastlu cleaned up and made more coherent and more general;
pcg> the Linux kernel is not badly written, but its organization is far
pcg> more haphazard.
Chris> I'm not convinced there's much difference in stability; I've
Chris> heard many people say their Linux systems stay up many months at
Chris> a time.
Well, I was not considering the stability in terms of kernel crashes,
but in architectural terms. The distinction of BSD and Linux is that
source is available, i.e. they are ideally suited to kernel work. The
way the Linux kernel is structured is not as stable (and elegant) as
that of the BSD kernel; some good people have given quite a bit of
thought to that over the past half a dozen years. Major subsystems are
still being tossed into the Linux kernel by the day... Linus writes nice
code, but it is still moving rather rapidly. Most of the BSD kernel is
rather stable, in this sense. For example the FFS, and the networking
code, and the space allocators, and ... Linux is nice, but BSD4 has the
benefits of a longer and maybe more distinguished history behind it.
Chris> As for architectural elegance, my impression is that this is not
Chris> something that Linus was initially shooting for---but perhaps
Chris> something that will grow as, [ ... ] By contrast, 386BSD seems to
Chris> have gone the opposite direction, with lots of grim
Chris> architecture-dependent hacks in it, and NetBSD trying to pull
Chris> back the other way.
Well, Linux is a much newer technolopgy than BSD; I'd say that Linux is
currently at about the BSD4.1c level, i.e. circa 1982 in the BSD
evolution. I regard 386BSD as a temporary hack waiting for the much
dreamt-of release of BSD4.4-Lite. As such the Jolitz team is doing a
very nice work; most of it, I reckon, will be folded back into BSD4.4,
especially drivers and the like.
Chris> and about the wonderfully cheap price of 340M disks these days;
The cheap small capacity drives are all IDE, and I don't like IDE
drives, simply because it seems that in the long run a single SCSI host
adapter is the better bet. ISA slots are not that abundant a resource in
many baby AT motherboards; and as somebody reminded me by mail, in
practice only SCSI boards do bus mastering, which can be a big win.
Chris> The last point to address is SCSI. I did consider this for a
Chris> while, but today (this year, nor probably next year) I just don't
Chris> need a CRROM or a backup device; if I did, I would have paid up
Chris> for SCSI.
Ah, if you are lucky enough to be able to rely on some net connected
system for both... But my machine is, for example, standalone, and so
are many personal use machines...
Crossposted-To: comp.os.386bsd.questions,comp.sys.ibm.pc.hardware,
comp.windows.x.i386unix
From: michaelv@iastate.edu (Michael L. VanLoon)
Subject: Re: SUMMARY: 486DX2/66 for Unix conclusions (fairly long)
Date: Wed, 14 Jul 1993 04:53:54 GMT
In < PCG.93Jul13210635@decb.aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:
>>>> On 13 Jul 93 11:42:41 GMT, davidg@implode.rain.com (David Greenman)
>>>> said:
>David> It is true that 386BSD as it is shipped does not support have
>David> libraries. It is *not* true that it's total VM must be backed by
>David> swap. In fact if you want you can have *no* swap. The total VM in
>David> 386BSD is memory + swap. 386BSD's VM system has nothing in
>David> common with original BSD; 386BSD's VM system is derived from Mach
>David> 2.5.
>pcg> On the other hand Linux does no swapping. However the BSD swapper
>David> This is wrong, too. 386BSD does *not* swap. The swapping code has
>David> not yet been written. 386BSD only pages.
4.3BSD *pages* when system load is light. This means it takes from a
process a small page that hasn't been used very recently (it's not in
the processes working set) and puts that page out to disk in the swap
area--it doesn't take the entire process. It then pages in the new
process page, either from the swap area if it was paged out
previously, or from the filesystem if it's an executable that is being
demand-paged in and this is a new page. This is a quick operation.
If system load is very heavy, however, paging would take more time
than actually running processes, so the system *swaps*. Swapping
involves finding the largest process that has gotten the most cpu time
recently and writing its entire user state to the swap partition.
This memory is then used to either swap in a previously swapped
process, or page in a new process from the filesystem. Swapping
requires more time than paging since it's more disk intensive, but it
also frees up a lot more memory by swapping out an entire large
process, allowing the remaining processes to run a little more easily
for a short time.
That is the model for 4.3BSD (in simple terms). I don't know how
completely or carefully 386BSD or NetBSD follow this model.
--
==============================================================================
Michael L. VanLoon Project Vincent Systems Staff
michaelv@iastate.edu Iowa State University Computation Center
==============================================================================
Crossposted-To: comp.os.386bsd.questions
From: deraadt@fsa.ca (Theo de Raadt)
Subject: Re: SUMMARY: 486DX2/66 for Unix conclusions (fairly long)
Date: Wed, 14 Jul 1993 14:16:51 GMT
In article <PCG.93Jul13212000@decb.aber.ac.uk>
pcg@aber.ac.uk (Piercarlo Grandi) writes:
> Chris> As for architectural elegance, my impression is that this is not
> Chris> something that Linus was initially shooting for---but perhaps
> Chris> something that will grow as, [ ... ] By contrast, 386BSD seems to
> Chris> have gone the opposite direction, with lots of grim
> Chris> architecture-dependent hacks in it, and NetBSD trying to pull
> Chris> back the other way.
I can't resist.
386BSD had lots of krufty architecture-dependent hacks in it. To those
who hold portability very highly, it was an ugly mess. Yetch.
This is exactly what NetBSD has already done in the current source
tree. It's fairly clear that the architecture-dependent hacks have
been pulled out now, and, I might even say we're cleaner in that
respect than 4.3reno was.
I will side step the issue of giving evidence for this, because I
might spoil someone's release announcement :-) :-)
> Well, Linux is a much newer technolopgy than BSD; I'd say that Linux is
> currently at about the BSD4.1c level, i.e. circa 1982 in the BSD
> evolution. I regard 386BSD as a temporary hack waiting for the much
> dreamt-of release of BSD4.4-Lite. As such the Jolitz team is doing a
Hmm. You might be alone with that viewpoint..
> very nice work; most of it, I reckon, will be folded back into BSD4.4,
> especially drivers and the like.
I think you might be even MORE alone with that viewpoint . . .
--
This space not left unintentionally unblank. deraadt@fsa.ca
From: eric@tantalus.nrl.navy.mil (Eric Youngdale)
Crossposted-To: comp.os.386bsd.questions,comp.sys.ibm.pc.hardware,
comp.windows.x.i386unix
Subject: Re: SUMMARY: 486DX2/66 for Unix conclusions (fairly long)
Date: 14 Jul 93 18:11:31 GMT
In article <michaelv.742625634@ponderous.cc.iastate.edu>
michaelv@iastate.edu (Michael L. VanLoon) writes:
>4.3BSD *pages* when system load is light. This means it takes from a
>[...]
>If system load is very heavy, however, paging would take more time
>than actually running processes, so the system *swaps*. Swapping
>[...]
Thanks for the explanation. As has been pointed out before, linux does
not swap in the traditional sense - since the linux memory manager is not
written to be a clone of some other memory manager, things are different in a
number of ways from a classical memory manager. One major difference is that
there is no minimum number of pages that the memory manager wants to keep in
memory for each process. This means that a sleeping daemon can in fact have
all of it's pages removed from memory (the kernel stack page and the
upage are not removed from memory as apparently some other schemes allow).
When the linux kernel needs memory, it goes through and looks for pages
that have not been accessed recently. If the page is dirty, this means that
instead of writing it to the swap file, it can simply be reused immediately.
Linux demand loads binaries and shared libraries, and the idea is that any
clean page can simply be reloaded by demand loading instead of pulling it from
a swap file. Thus it tends to be only dirty pages that make their way into the
swap files, but it also means that the kernel can free up some memory by
reusing some code pages without ever having to write them out to disk.
Linux tends to share pages whenever possible. For example, all
processes running emacs will share clean pages for both the emacs binary and
sharable libraries (these pages are also shared with the buffer cache). This
means that swapping out a process that is running the same binary as some other
process gains very little since much of the actual memory cannot be freed.
Paging still works well in this scheme, because it is still easy to find out
which pages not not been used recently by a particular process, and we can
easily remove unused pages from the page tables for processes on the
system. Once the usage count for a particular page goes to 0 (i.e. not in
anyone's page tables, and not in the buffer cache), we can reclaim the page
entirely to be used for something else.
I guess the way I see it, the only advantage of swapping is that you
are effectively keeping particular processes out of memory longer than would
otherwise be the case, which tends to reduce thrashing. The only time when the
linux approach breaks down is when you have too many computable processes
fighting for access to memory, and in principle the linux scheduler could be
modified to temporarily lower the priority of some of these processes and
ultimately achieve the same result with paging. With the current kernel, any
idle processes will always be "swapped" via paging as it is, so it is not that
clear that this needs to be done.
-Eric
--
"When Gregor Samsa woke up one morning from unsettling dreams, he
found himself changed in his bed into a lawyer."