View Single Post

   
  #2 (permalink)  
Old 01-16-2008, 07:06 PM
Don Morris
 
Posts: n/a
Default Re: Safe limits for shared memory allocation?

nick.battle@gmail.com wrote:
> I have a 32-bit SHARED_MAGIC application that needs to allocate as much
> shared memory as it can. I understand the total of all 32-bit shared
> memory is limited to 1.75Gb on HP-UX 11.00 (unless I use SHMEM_MAGIC).
> Assume I have the shmmax and my swap area big enough to actually allow
> allocation of the 1.75Gb.
>
> If I literally allocate as much shared memory as is available (maybe in
> multiple segments, to overcome the 1Gb quadrant limit), it will give it
> to me, but I gather other 32-bit applications that want to map shared
> libraries won't be able to execute. As our application is long-lived,
> this would be a problem!
>
> I'm trying to find out the minimum "spare" shared memory the
> application should leave on the system to ensure everything *else* can
> still run. I can see that this depends on what else I want to run(!),
> but if it's just a matter of the usual chatter of shell scripts and
> editors and so on, what sort of ballpark are we talking? 10s of Mb? or
> 100s? More? How could I determine the safe limit?


Nick --

(I said some of this over on ITRC, but no reason not to repeat myself).

I can't comment on the typical shared library/shared object requirements
on your average box (given that doing development/testing is hardly
likely to have the same workloads... we're either mostly-idle or
stress testing for exhaustion). I would think, however, that you'd
have a difficult time determining a safe limit with accuracy -- simply
because you could never be positive that all the applications in
question had all their dynamic libraries loaded up.... if user foo's
emacs needed to load up the "Butter your Toast" module (emacs does
include the Toaster+AutoCAD module as well as the OS and Web Browser
now, right? ), your carefully calculated estimates are voided.

Your best bet would be to put your application in a Memory Window where
if possible you share Q2. That would allow you 2Gb of shared memory
within your window before you use any from the Globally shared Q4
(which is where shared libraries start). Even if you can't share Q2,
if you can start your app, set up your segment(s) as 1.5Gb or whatnot
[assuming that there's some library already mapped in Q4, which is a
pretty safe bet usually] even if you exhaust the global Q4 then the
"normal" applications running in the Global Window will still be able
to map their libraries in q3 (the fallback). This means that your
app (and any in a different window) wouldn't be able to map those
libraries... but if your app is already running and you've reached
your steady state, you won't care. (Oh, be sure that your app isn't
creating the Shared Memory object with MAP_GLOBAL/IPC_GLOBAL or
this is irrelevant... if you ask for Global, you get Q4 first).

Of course -- the best option would be to just recompile your app to
be 64-bit and have a couple of Tb to play with instead.

Don
Reply With Quote