Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!wuarchive!texbell!nuchat!squazmo!stan From: stan@squazmo.solbourne.com (Stan Hanks) Newsgroups: comp.unix.wizards Subject: Re: shared memory Keywords: portability Message-ID: <1989Dec13.225842.3502@squazmo.solbourne.com> Date: 13 Dec 89 22:58:42 GMT References: <11383@csli.Stanford.EDU> <1989Dec12.005555.20618@virtech.uucp> <21223@mimsy.umd.edu> <1989Dec12.053453.497@virtech.uucp> Reply-To: stan@squazmo.UUCP (Stan Hanks) Organization: Solbourne Computer Inc., Houston NSE Outpost and Sales-Slug Haven Lines: 64 In article <1989Dec12.053453.497@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes: >In article <21223@mimsy.umd.edu>, chris@mimsy.umd.edu (Chris Torek) writes: >> In article <1989Dec12.005555.20618@virtech.uucp> cpcahil@virtech.uucp >> (Conor P. Cahill) writes: >> As I understand it---which is not to say that it is so, for I have >> never seen the SysRel% 1, 2, or 3# code itself---the total amount of >> shared memory allowed per-system is reserved at boot time, is not >> pageable, and is effectively taken away from the rest of the system. >I don't believe that shared memory is reserverd at boot time because >I worked with a project that implemented shared libraries using shared >memory segments and we maxed out all shared memory configuration >options without it having a detrimental effect on memory available in >the system. Another issue is that the pagability of shared memory is >controlled by a shmctl() call to lock/unlock a segment in memory. Early System V (i.e. before they got around to having to number the releases) had the shared memory stuff configured at boot time. The kernel sort of malloc'd a chunk of memory that was as big as the total of all the shared memory you could have and mapped your accesses into it when you shmget'd (shmgot?) it. Remember though that this was VAX hardware, and that System V didn't even have the remotest notion of demand paged virtual memory. Hell, they even just mapped the UNIBUS once at boot time, rather than supporting dynamic remapping to make DMA device support more rational. When the BRL 'System-V-under-BSD' emulation code hit the street, people had to re-think things. Simple subsumptive reasoning indicated that the clear win was to jam as much of System V as possible into BSD rather than the opposite. And so it went. The SunOS implemention (well, at least the first one I saw source to -- Guy Harris, where are you on this?) used dynamically allocated and mapped memory pages. The only thing that gets allocated at boot time is an array of SHMMNI struct shmid_ds's for use as the descriptors. You wanted to create a segment, OK, fine. Here it is. When you free the segment, the pages went back to being usable as any other page. Looks like the original interface. Works *MOSTLY* like the original interface -- unless you count on those pages being tacked down somewhere in kernel memory. I'm not aware of any "current" implementations that are done the "old" way (i.e. permanently mapped kernel memory) but that doesn't mean that they're not out there. I've scrupulously avoided everything with a *86 in it, ditto all vanilla System V boxes for MANY years, so I'm likely to be missing something. Still, I'd think that there are some real dangers of developing code that couldn't deal with smaller than expected segment sizes or limits on the number of segments that you can have or the total space that can be occupied by shared memory. You can either do what Oracle does, and include instructions on how to modify the kernel to increase these values; or tell the customer to suck rocks; or write adaptible code that determines what resources it has available and makes the most of them. Regards, Stanley P. Hanks Science Advisor Solbourne Computer, Inc. Phone: Corporate: (303) 772-3400 Houston: (713) 964-6705 E-mail: ...!{boulder,sun,uunet}!stan!stan stan@solbourne.com -- Stanley P. Hanks Science Advisor Solbourne Computer, Inc. Phone: Corporate: (303) 772-3400 Houston: (713) 964-6705 E-mail: ...!{boulder,sun,uunet}!stan!stan stan@solbourne.com