adam@cs.UAlberta.CA (Michel Adam; Gov't of NWT) (06/16/91)
In article <1991Jun14.225216.23361@cfctech.cfc.com> kevin@cfctech.cfc.com (Kevin Darcy) writes: >In article <1991Jun13.192444.7500@ucunix.san.uc.edu> adams@ucunix.san.uc.edu (J. Adams - SunOS Wizard) writes: >>In article <1991Jun13.122803.25362@ims.alaska.edu> floyd@ims.alaska.edu >>(Floyd Davidson) writes: >>>[...] >>>In article <1991Jun13.065207.10089@ucunix.san.uc.edu> >>>adams@ucunix.san.uc.edu (J. Adams - SunOS Wizard) writes: >> >>System V rel. 2.1 and later and 4.1BSD and later adopted different >>philosophies regarding the implementation of demand-paged virtual >>memory. The BSD systems, being research-oriented and likely to be used >>by programmers with a more intimate knowledge of the inner workings of >>the O/S, chose simple, less elegant approaches to memory management with >>provisions, such as the vfork() call, for the programmer to tune the >>system to the application. In 4.xBSD, swap space is allocated at the >>birth of a process, with enough space being allocated to contain the >>entire virtual image of the process in its initial state >>(text+data+BSS), excepting of course malloc'd (heap) space obtained [ ... ] > >Although I'm no kernel hacker, I will point out, from a sysadmin's point-of- >view (with advice from the higher levels of AT&T support/development people) >that later SysV implementations still retain vestiges of the old virtual >memory scheme you describe: on an AT&T 3B2/600 running r3, for instance, the >kernel always attempts to map two -entire- sets of -contiguous- pages in the >swap area for every process upon startup, whenever sbrk() is called for more >memory, and so on. One of these sets is for paging, and the other, for >swapping. If, for some reason, there is not enough contiguous space available >to allocate one of these sets, the kernel spits out a "getcpages: cannot >allocate X contiguous pages" console message (X being some-number-or-other). >If there is insufficient contiguous space to map EITHER page, new processes >will die on startup, or ungrowable processes will (usually) seg violate, with >all of this mayhem accompanied by delightful kernel messages such as "growreg: >unable to allocate ...", or "dupreg: unable to allocate..." or "uballoc: ><something-or-other>" spewing on the console. > >The algorithm for mapping this swap space is unknown to me, but it appears to >be imperfect - from time to time, one of our 3B2's or another will suddenly >experience these symptoms for no particular reason, and plenty of available >swap space. Once it starts, even programs with relatively small run-time >images (e.g. /bin/cat) will then die on startup, with the kernel complaining >that it cannot allocate swap-area space. Obviously, the only cure at that >point is to reboot... > >Perhaps AT&T has been slow in -implementing- the VM "elegance" of which you >speak? I see very little of it on their own products. > I seem to remember a discussion on this subject, 6 to 12 months ago, on the problems with insufficient RAM available on the AT&T 386 machines, (must have been a SYS V Ver. 3.something). One comment that struck my mind at that time was that for some reason, there was a recommendation to have as much real RAM as the swap partition's size ( I may be mistaken on that ...), to avoid some kind of trashing. There was an explicit reference to the implementation by Convergent, for the 7300, being somewhat different and managing to avoid this problem. There where numerous references to the Bach book, but I don't remember if the difference between the CT version for the 3B1 and the other versions running on 386 machine was described. Can someone who archived these articles look up the conclusion? What was it that CT did differently in their implementation? (Can someone with access to the kernel source find out?) >>-- >> Jim Adams Department of Physiology and Biophysics >>adams@ucunix.san.uc.edu University of Cincinnati College of Medicine >> "I like the symbol visually, plus it will confuse people." >> ... Jim Morrison > >------------------------------------------------------------------------------ >kevin@cfctech.cfc.com | Kevin Darcy, Unix Systems Administrator >...sharkey!cfctech!kevin | Technical Services (CFC) >Voice: (313) 759-7140 | Chrysler Corporation >Fax: (313) 758-8173 | 25999 Lawrence Ave, Center Line, MI 48015 >------------------------------------------------------------------------------ Michel Adam adam@cs.ualberta.ca (...!alberta!adam) or adam@iceman.UUCP (...!alberta!iceman!adam)