Re: SHMMAX (was Re: using cdrecord)

["Wes Bauske" <wsb paralleldata com>]

Christopher Curtis wrote:
> 
> On Mon, 3 Aug 1998, Wes Bauske wrote:
> 
> > It depends on how the system works. A SHM segment takes up
> > one of 16 256MB segments on older RS/6000 systems that you can't
> 
> Well, that doesn't really have anything to do with the current problem.
> Unless you're saying that 256MB segments are the drawback.  If you're
> talking about the 16 slots, then making the segment size too small would
> use more slots than needed.  If it's just a matter of divvying up 4GB of
> address space, I'm sure there has to be a better medium than 16 slots of
> 256MB or 1024 slots of just under 4 MB.
> 

The key is there are only so many slots. How much VM you
attach is up to you. Richard's answer explains the real
issue on Alpha. Not being pagable and being able to make
a big SHM segment would cause major problems.

> > use for other memory so if you use several SHM segments, you
> > can decrease your available memory within the process significantly.
> > Anyone know if Alpha's do something similar??
> 
> How often is shared memory really needed?  This strikes me as being
> something needed primarily for pre-threaded apps.  I'm not saying it's
> useless, but I think that there is little demand for it in general and
> that demand is not increasing.  I think it's a relatively low-demand type
> of thing.  UNIXen are primarily dealing with pipes, not shm...
> 

SHM segments are very useful on an SMP where you want
to do parallel processing. It's faster than a pipe 
because a pipe copies to kernel land and back and
SHM is directly in your memory space so there's
only one copy to it and the next process can get it.


> > Actually, couldn't you make a small mod to cdrecord to
> > do some minor searching to figure out how much SHM it
> > can get?? Then, if it didn't get the optimal amount, issue
> > a warning and proceed with the less optimal amount.
> > A simple start at 4MB and decrement by 4KB until it
> > works would be sufficient...
> >
> > That way, there is less user intervention until one
> > creates a coaster...
> 
> Well, it'll all be handled over the web so the actual parameters are going
> to be hard coded anyway.  It's no biggie, but I would think that it would
> be a bigger general problem.  X uses shared memory, as does the GIMP
> (though I don't know how the two use it in concert if at all).  What this
> is used for I don't know, but I would gladly give up 512 or 768 shared
> memory segments in leiu of a larger maximum shared memory pool.
> 
> > At $.99 a blank CD now, it's not too painful to screw
> > up but I've never had a buffer underrun with cdrecord.
> 
> It's not so easy to happen unintentionally often.  I was writing at 4x
> while flipping back and forth in windowmaker and loading the GIMP trying
> to make it swap as much as possible without renice'ing the cdrecord
> processes.  There were 29 underruns in total out of 22,000+ sectors
> (336,000+ blocks).  Under normal load this should be rare.  This was also
> a 2MB buffer, not the 3MB I've set it at now.
> 

Your machine actually swaps while running??
That's bad news. I'd try to make sure that for the
workload I put on the machine, it has sufficient
real memory and pretty much never swap. Memory
is so cheap now.

> > From what I remember, the default Solaris 2.5 SHM max
> > is only 1MB so 4MB isn't that bad.
> 
> I find that difficult to believe.  It's probably 4MB.  =)
> 

Humm... I just ran a test with 1MB + 2 bytes and it
fails with "Unable to create shm segment (Invalid argument)".
There is supposed to be a way to set it but I can't
find it in my book at the moment.


Wes