On Wed 15 Sep, Thilo Manske wrote:
> > It's a boot parameter you can set, on a RISC PC you type it into the 
> > options box and it magically gets passed to the boot program.  I've no 
> > idea how it's done on other ARM boards, though I'd quite like to know how 
> > you do it on a SHARK.
> I guess the way that should always work is to compile a kernel with  a
> higher NPROC value (if undefined set to 20+16*MAXUSERS, see <sys/param.h>).
> 
> I've noticed that my settings in !RiscBSD were way to low -
> (much lower than the defaults... (64 actually!!!) )
> I never cared to look into it for years now... F*CK!

I think you are getting two things confused here. The NPROC value is the one
reported by sysctl kern.maxproc. This is a hardwired maximum limit on
number of simultaneous processes. This is not the same as the maxusers or
PMAP_STATIC_L1S value which is the actual memory put aside for the L1 tables
at boot time. For instance, my kernels have PMAP_STATIC_L1S=192, but
sysctl.kern.maxproc gives 532.

> Thank you for your help, maybe we don't even have a real problem here...?!?

We do most seriously have a problem here. The maxproc/PMAP_STATIC_L1S value
is the number of L1 slots statically allocated at boot time. Each one is
16kB. If you tried to have maxproc = NPROC then 16 * 532 = 8512kB which would
lock out 8.5MB of your RAM at boot time (it can't be swapped out). Other
ports dynamically allocate the tables, AFAIK and hence don't have this
problem.

I've not tried hitting the limits on recent kernels, but certainly with
the 1.3 kernels, in my experience the machine stiffed long before it ever
even reached the maxproc number if maxprox > 192 (a RiscPC was OK, IIRC. But
the CATS was well messed up). And a CATS wouldn't boot if maxproc > 128 and
RAM > 64MB. I posted quite a lot about this a year ago and never got a single
reply.

The problem is that most people working on NetBSD/arm32 seem to view it
as a research interest rather than a potential server box. The L1
limits mean that it's not a lot of use as an Apache web server (esp. if
you use CGIs) as you just run out of processes or the machine stiffs.

This is my understanding of the situation. I'd appreciate a detailed
description of the problem. Is it something like the following?

Static L1 tables are allocated to guarantee a number of 16kB blocks
  composed of contiguous pages.
Once those have been exhausted, the system will try to allocated further
  blocks dynamically (but usually fails as it failed to get contiguous
  blocks).

-- 
Dr. Stephen Borrill, Director and Principal Engineer
Precedence Technologies Ltd             Tel: +44 (0) 1223 562 500
86 Kings Hedges Road                    Fax: +44 (0) 1223 563 522
Cambridge, CB4 2PA, United Kingdom      WWW: http://www.precedence.co.uk/