From owner-freebsd-questions  Fri Sep  6 11:30:11 1996
Return-Path: owner-questions
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id LAA18402
          for questions-outgoing; Fri, 6 Sep 1996 11:30:11 -0700 (PDT)
Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA18373
          for <freebsd-questions@FreeBSD.ORG>; Fri, 6 Sep 1996 11:29:59 -0700 (PDT)
Received: (from root@localhost) by dyson.iquest.net (8.7.5/8.6.9) id NAA03415; Fri, 6 Sep 1996 13:29:40 -0500 (EST)
From: John Dyson <dyson@dyson.iquest.net>
Message-Id: <199609061829.NAA03415@dyson.iquest.net>
Subject: Re: SYSV Shared Memory Question
To: rwm@MPGN.COM (Rob Miracle)
Date: Fri, 6 Sep 1996 13:29:40 -0500 (EST)
Cc: freebsd-questions@FreeBSD.ORG
In-Reply-To: <3.0b11.32.19960906110535.00727e2c@central.TanSoft.COM> from "Rob Miracle" at Sep 6, 96 11:05:37 am
Reply-To: dyson@FreeBSD.ORG
X-Mailer: ELM [version 2.4 PL24 ME8]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-questions@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> We need a boat load of SYSV shared memory and we get a Kernel panic when we
> try to request it.  Here are the specifics:
> 
> On our FreeBSD 2.x.x (we have tried 2.1.0, 2.1.5, and 2.2.snap (most recent))
> when we set SHMMAXPGS to 22000 and SHMALL to something over 30000, we get a
> kernel panic in kmem_suballoc of type 3.
> 
The problem is fixable, but...
>
> My questions are:
> 
> Is there a limit to the amount of SYSV shared memory in FreeBSD(any version)?
> What are the real meanings of SHMMAXPGS, SHMALL, SHMMAX, and other shared memory
> options?
>
Unfortunately, the code allocates Kernel Virtual space for the shared
region.  That is TOTALLY unnecessary, but that is how it was implemented.  I
can probably fix it, but I was planning on a total rewrite.  Of course,
a rewrite would be in a longer timeframe than you are interested in.

> 
> We really want to move away from our DecStations and move to PCs but this is
> a big sticky issue.
> 
I will try to see if there is a work-around that I can create.  The code
is calling for a rewrite though.  (Even though FreeBSD has LOTS of Kernel
virtual space: a little less than 256Mbytes, the code still wastes it
unnecessarily.)

I will try to see what I can do this weekend -- I have some ideas.  I don't
have any SV shared mem test tools, so if I get anything implemented -- you'll
have to test it :-)!!!

John
dyson@freebsd.org