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.