Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!hc!beta!jlg
From: jlg@beta.UUCP (Jim Giles)
Newsgroups: comp.arch
Subject: Re: VM needed for rapid startup
Message-ID: <20005@beta.UUCP>
Date: 6 Jun 88 20:09:54 GMT
References: <19730@beta.UUCP> <4332@killer.UUCP>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 18

In article <4332@killer.UUCP>, elg@killer.UUCP (Eric Green) writes:
> [...]
> None of which has anything to do with the "problem" of "disk access so slow
> that it takes longer to load the page than it takes to execute it". VM makes
> little difference, there.

[That is, VM makes little difference when the user code does it's own
 segmentation].

Well this is EXACTLY true.  It makes little difference - which means it
makes a difference.  The reason that the user code, in these cases, does
its own segmentation is that the runtime cost of a page or segment fault
is so large (because the disk is so slow relative to memory).  Since the
user code is doing its own segmentation, the hardware for VM is not
required.  Therefore, any additional overhead caused by the presence of
such hardware is undesireable.  This overhead usually ammounts to about
5-10% slowdown of scalar memory references due to hardware table lookups.
This is 'little difference', but it sufficient to reject the machine
against one with similar design that doesn't have the VM penalty.