shared memory

[Stan Hanks]

In article <1989Dec12.053453.497 at virtech.uucp> cpcahil at virtech.uucp (Conor P. Cahill) writes:
>In article <21223 at mimsy.umd.edu>, chris at mimsy.umd.edu (Chris Torek) writes:
>> In article <1989Dec12.005555.20618 at virtech.uucp> cpcahil at 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 at 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 at solbourne.com