johnl@ima.UUCP (07/08/85)
/* Written 1:22 am Jul 8, 1985 by thomas@utah-gr in ima:net.unix-wizards */ > The problem is that the initial design of the Vax (750?) had a flaw that > made copy-on-write VERY difficult (impossible?) to do. So, the vfork > kludge was the only workable solution to avoid copying an entire process No it wasn't -- vfork really has to be chalked up to laziness. It would have been entirely workable to do copy-on-touch in the stack segment (which was where the copy-on-write pages didn't work.) Considering how little stack data is read but not written, the performance would have been about the same. On machines like the PDP-11, vfork makes more sense since the segments are too big to do practical copy-on-anything. John Levine, ima!johnl
tp@ndm20 (07/10/85)
>vfork is a botch. The way to implement fork on a paged system is to set >up both processes with identical data page tables as well as text pages, >and make the data pages read-only. When a write to a data page causes >a fault, duplicate the page and make each copy writable. Swapping gets According to an AT&T representative at the January uniforum here in dallas, one of the changes that will soon be made to SysV is to implement the "Copy-on-modify" protection on a page (exactly what you describe) as part of the SysV virtual memory code (which does exist in SVR2v4 on the 3b20, though nobody seems to have ported it (are they releasing it?)). Other enhancements he mentioned were Dennis Ritchie's Streams package and a distributed file system (actually the streams package is the implementation vehicle for the dfs). The above is subject to a 6 month memory lag. Somebody please correct me if I'm wrong on these (fast, before the fallout hits), but I'm pretty sure about those particular items. Thanks, Terry Poot Nathan D. Maier Consulting Engineers (214)739-4741 Usenet: ...!{allegra|ihnp4}!convex!smu!ndm20!tp CSNET: ndm20!tp@smu ARPA: ndm20!tp%smu@csnet-relay.ARPA
keith@motel6.UUCP (Keith Packard) (07/11/85)
In article <22500003@ima.UUCP> johnl@ima.UUCP writes: > >/* Written 1:22 am Jul 8, 1985 by thomas@utah-gr in ima:net.unix-wizards */ >> The problem is that the initial design of the Vax (750?) had a flaw that >> made copy-on-write VERY difficult (impossible?) to do. So, the vfork >> kludge was the only workable solution to avoid copying an entire process > >No it wasn't -- vfork really has to be chalked up to laziness. It would >have been entirely workable to do copy-on-touch in the stack segment (which >was where the copy-on-write pages didn't work.) Considering how little >stack data is read but not written, the performance would have been about >the same. > >On machines like the PDP-11, vfork makes more sense since the segments >are too big to do practical copy-on-anything. > >John Levine, ima!johnl No, it's not because the segments are too large. It's because you must have contiguous physical addressing on the pdp, otherwise swapping becomes a nightmare (very important on pdp's remember) and physical i/o becomes impossible (only the cpu goes through the virtual memory map, not the i/o devices). many portions of the kernel depend on contiguous physical addresses of unix processes; true copy-on-touch demands *real* virtual memory. keith packard speaker-to-pdp ...!tektronix!reed!motel6!keith ...!tektronix!azure!keithp
henry@utzoo.UUCP (Henry Spencer) (07/14/85)
> ...it's not because the segments are too large. It's because you > must have contiguous physical addressing on the pdp, otherwise > swapping becomes a nightmare (very important on pdp's remember) and > physical i/o becomes impossible (only the cpu goes through the > virtual memory map, not the i/o devices)... Not true, actually. Few processes use physical i/o; they can always be forced to be contiguous. How bad the swapping issue is depends on the tradeoffs between disk speed and memory scarcity (but note that on an 11 with a Unibus map (70, 44, 24[?]) there is no problem at all). Non-contiguous allocation isn't trivial, but it's not impossible either. Proof by example: it's been done. The problem with copy-on-write "smart" forking on the 11 is, as stated, that there are big segments and relatively few of them, so you probably end up copying most of the program anyway. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry