Path: utzoo!attcan!uunet!husc6!uwvax!rutgers!mtunx!mtune!codas!peora!ge-dab!ge-rtp!edison!toylnd!dca
From: dca@toylnd.UUCP (David C. Albrecht)
Newsgroups: comp.sys.amiga
Subject: Re: Amiga UNIX
Message-ID: <221@toylnd.UUCP>
Date: 14 Jun 88 06:02:29 GMT
References: <211@laic.UUCP> <3663@cbmvax.UUCP> <1872@sugar.UUCP> <134@ssdis.UUCP> <2106@sugar.UUCP>
Organization: Dave & Anne in Charlottesville, VA
Lines: 78

In article <2106@sugar.UUCP>, peter@sugar.UUCP (Peter da Silva) writes:
> In article <217@toylnd.UUCP>, dca@toylnd.UUCP (David C. Albrecht) writes:
> > > 	1) The 68000 supports an MMU just fine.
> > A single by itself 68000 does not to my knowledge 'support' an MMU.  Having
> > a second 68000 which takes over on a page fault hardly constitutes 'support'.
> 
> For the 14th time, an MMU does not imply demand paged virtual memory. There
> are plenty of reasons for having an MMU even if you can't handle page faults.
> Memory protection, for one, and providing a logical zero. Even if you can
> handle page faults you might not want to do more than kill the process with
> a SIGSEGV. Look at the PDP-11.
Point granted but confusing.  Why use a catch-all term when it isn't
appropriate.  Yes, the 68000 support memory protection and page relocation
etc.  By my definition, however, it doesn't support an 'MMU' unless it
supports all the functions of a typical device which falls under this
designation i.e. including demand paged VM.  I guess your definition for
'support' is a little different.  I wouldn't say that a FP chip 'supported'
'IEEE floating point' if it only did add and subtract.
> 
> > > 	3) Virtual memory often gives you virtual performance.
> > I've seen this kind of assertion many times on this newgroup and I still
> > think it is a crock.
> 
> Comparing a PDP-11 running Berkeley UNIX (3BSD) with a VAX running Berkeley
> UNIX (4BSD). The PDP-11 gave a lot better response time, and supported more
> users, with less real memory than the VAX. And *this* was with an overlaid
> kernel in the '11!
> 
So?  And you think the VAX would have done better in this comparison if you
had taken out the VM and mapped direct to real memory?  Uh huh.
I respectfully suggest that conclusions drawn on a multi-variable problem
through an intuitive leap to a pet-peeve result are often fraught with error.
>
> If you can find any indication that I even implied that (1) you can have a
> good UNIX without memory management, or (2) that an MMU and VM are equivalent.
I didn't say you implied it, and didn't even mean to imply that you implied
it :-).  I simply was making the point that VM is usually an available
option once you have an MMU (my definition) in the system.  And it is my
opinion that VM is not high cost yet it provides very real benefits.
> 
> By the time 3BSD faded out, it had some amazing overlay support. You could
> take your VAX program with huge code and just compile and link it and it
> would automagically become overlaid. This is the system I'm talking about.
> About the only thing the VAX had that we PDP-11 weenies missed was Berkeley
> Job Control, and they got that after I left.
> 
> As a side comment, the 128K limit *is* the reason paging wasn't implemented on
> the '11... even though the hardware supported it.
> 
Maybe you should convince the people at BSD that they should put an intelligent
overlay manager on the VAX so that everyone will be paging in and out of a
128K segment instead of using up all of memory.
Bongo roll....bump rest bump bump bump rest bump bump bump rest...flute run.
Lights fuse.....Good luck.
> > Of course virtual memory isn't free but neither is it that expensive
> > given that you have a reasonable amount of physical memory to back it up.
> 
> I'm not saying that VM is undesirable, just that if you have enough memory
> that you never page (which is basically what you're talking about) you might
> as well not have the page table overhead.
I could have a virtual size which was 50% larger than my real memory
and I would probably rarely page.  I could put in physical memory but
I have a disk, I have an MMU (my definition), it doesn't cost much,
why not use VM?  I also have the option to
run processes that won't go in real memory.  Maybe they will run poorly but
they will run.  That is more than you can say for real memory only machines.
VM gives you a valuable commodity, flexibility.  You can be cheap yet
sacrifice only performance instead of compatability.  The 3b1 on my desk
has 3M of memory in it and a 4M virtual space.  There are people out there
with 512K machines (gack!) who can run all the same stuff I can, slow but
they can run it.  No one has ever said that VM is better than the real stuff
just that it provides the effect of real memory.  It has always been and will
always be a cost/performance tradeoff.  There is still an order of
magnitude price of memory/price of rotating media.  If you don't use VM
you have lost very little.  If you need it and don't have it you are shit
out of luck.

David Albrecht