Subject: Re: maxproc on the CATS
To: S.J. Borrill <sjb42@cus.cam.ac.uk>
From: Mark Brinicombe <mark@causality.com>
List: port-arm32
Date: 08/27/1998 21:37:33
On Thu, 27 Aug 1998, S.J. Borrill wrote:

> As you know, I've got two CATS. One older with a 1.3F kernel (dating from
> June) which is the one showing the above behaviour and a newer one
> (dating fromwhich
> doesn't (but see below). 
> 
> > Any chance of a trace when you drop into the debugger ?
> 
> _panic
> _main
> _kernel_text
> 
> just after the panic: fork init error

Hmm, I'll try and check at the 1.3F kernel and see if I can re-create it.

> > ne thing to note, the maxproc option will only work as long as
> > PMAP_STATIC_L1S is not defined as an option in the config file.
> 
> Ah. Unpacking the kernel source included on the disc of the new machine
> show that option PMAP_STATIC_L1S is set to 128 (which explains why all my
> experiments on that machine with maxproc were in vain). Interestingly,
> with PMAP_STATIC_L1S=128, I could start 146 processes. Why that number?

Ok. The allocation of the L1 page tables as 2 modes of operations. The
PMAP_STATIC_L1S determines the number of tables reserved at boot time. The
kernel will also attempt to allocate more if necessary as it is running.
This allocation is dependant on the pmap code being able to get the memory
with the require alignment. So more L1s are created until the dynamic
allocation fails. 146 is purely arbitaty and will be dependant on the way
your memory has been allocated and fragmented.

> With a recompiled kernel but without the PMAP_STATIC_L1S line things are
> different. maxproc=128 works fine (can have up to 146 processes running). 
> maxproc=256 gets further booting, but dies later on. When samba is
> starting, it dies with a permission fault in kernel by kernel. Trace
> shows: 
> 
> _panic
> _data_abort_handler
> _pmap_allocpagedir
> _pmap_pinit
> _pmap_create
> _uvmspace_init
> _uvmspace_alloc
> _uvmspace_fork
> _uvm_fork
> _fork1
> _sys_fork

I'll take at look at pmap_allocpagedir() This is the routine that will try
and allocate a new L1 page table.

> maxproc=192 appears to work fine, but it dies in the same way as above
> when more than 120 processes are running.
> 
> You didn't hardwire PMAP_STATIC_L1S=128 because that was the only one that
> would work did you? ;-)

Nope purely as typically I was only typically running at 80 odd processes
and thus 128 seemed a nice number.

Cheers,
			Mark