On Fri, 1 Jun 2001, Chris Gilbert wrote:

> > You might want to consider some sort of home-grown cache of L1 tables.
> > IIRC, the ARM uses a 16K table, so they can be tricky to allocate as
> > memory gets fragmented.  The cache would also allow you to keep the L1
> > tables "constructed", i.e. the kernel L1 PTEs always valied in the top
> > N slots of the table (the ARM is a single-address-space system, right?)
>
> Currently we use a list of l1pt's which which have that 16k attached to them.
> This is allocated at startup.  We use them until we run out, after which we
> allocate from available ram, which as you say fragments, however I'm not sure
> if it's the VM space that can't find the 16k or the real memory, I need to
> look into it further, I might even consider dropping the base of the kernel
> down to 0xE0000000 to gain oodles more space for kernel VM.  However before
> doing that I'd want to implement pmap_growkernel.

	Does that mean the kernel is out a 16k wired table per running
	process? If so, then you could keep a copy of the L1 table in
	with the pagable process information and have an allocated block
	of 'active processes L1 tables'. In order to run the process must
	have its L1 table information LRU copied into an active slot.

	The uVaxI has a related issue as all process page tables must be
	in a contiguous block of memory, so either you have a serious
	limit on process numbers or VM, or go the 'active set' route.