a180cee23b
deal with shortages of the VM maps where the backing pages are mapped (usually kmem_map). Try to deal with this: * Group all information about the backend allocator for a pool in a separate structure. The pool references this structure, rather than the individual fields. * Change the pool_init() API accordingly, and adjust all callers. * Link all pools using the same backend allocator on a list. * The backend allocator is responsible for waiting for physical memory to become available, but will still fail if it cannot callocate KVA space for the pages. If this happens, carefully drain all pools using the same backend allocator, so that some KVA space can be freed. * Change pool_reclaim() to indicate if it actually succeeded in freeing some pages, and use that information to make draining easier and more efficient. * Get rid of PR_URGENT. There was only one use of it, and it could be dealt with by the caller. From art@openbsd.org. |
||
|---|---|---|
| .. | ||
| compile | ||
| conf | ||
| dev | ||
| eisa | ||
| gio | ||
| hpc | ||
| include | ||
| pci | ||
| sgimips | ||
| stand | ||
| xio | ||
| Makefile | ||
| README.IPn | ||
| TODO | ||
$NetBSD: README.IPn,v 1.2 2000/06/16 04:15:39 soren Exp $
Arch (kernel) Models
------------- ------
IP2 IRIS 3000
IP4 4D/50, 4D/70
IP4.5 4D/60, 4D/80, 4D/85
IP5 4D/1x0
IP6 4D/20
IP10 (IP6) 4D/25
IP7 4D/2x0
IP9 4D/210
IP13 (IP7) 4D/3x0
IP15 (IP7) 4D/4x0
IP12 4D/30, 4D/35, Indigo R3K
IP17 Crimson
IP19 Onyx, Challenge M/L(/XL?)
IP20 Indigo R4K
IP21 Power Challenge, Power Onyx
IP22 Indigo2 ("Fullhouse")
IP24 (IP22) Indy ("Guiness"), Challenge S
IP25 Power Challenge R10K
IP26 Power Indigo2 R8K ("Teton")
IP27 Origin 200, Origin 2000, Onyx2
IP28 Power Indigo2 R10K ("Pacecar")
IP30 Octane
IP32 O2 ("Moosehead")
IP35 SN1 (?)