Re: kmem-pool-uvm

[yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)]

hi,

> The patch provided includes the changed extent as well as a changed
> implementation of kmem, which provides page aligned memory for
> allocation >= PAGE_SIZE. The interface between the pool-subsystem and
> uvm_km is changed by passing the pool_allocators page_size to the
> uvm_km functions, the idea behind this is to have multiply default
> pool_allocators with different pool-page-sizes to lower inner
> fragmentation within the pools.
> In order to support those different-pool-page-sizes the kernel_map and
> kmem_map gained caches for virtual addresses not only for PAGE_SIZE
> but low integer multiplies of PAGE_SIZE.
> These large then PAGE_SIZE caches are used by the the larger the
> PAGE_SIZE allocations in kmem.

why do you want to make subr_kmem use uvm_km directly?
to simplify the code?
i don't want to see that change, unless there's a clear benefit.

let me explain some background.  currently there are a number of
kernel_map related problems:

A-1. vm_map_entry is unnecessarily large for KVA allocation purpose.

A-2. kernel-map-entry-merging is there to solve A-1.  but it introduced
   the allocate-for-free problem.  ie. to free memory, you might need to
   split map-entries thus allocate some memory.

A-3. to solve A-2, there is map-entry-reservation mechanism.  it's complicated
   and broken.

B. kernel fault handling is complicated because it needs memory allocation
   (eg. vm_anon) which needs some trick to avoid deadlock.

C. KVA allocation is complicated because it needs memory allocation
   (eg. vm_map_entry) which needs some trick to avoid deadlock.

the most of the above can be solved by separating KVA allocation and
kernel fault handling.  (except C, which will be merely moved to a
different place.)

i implemented subr_vmem so that eventually it can be used as the primary
KVA allocator.  ie. when allocating from kernel_map, allocate KVA from
kernel_va_arena first and then, if and only if necessary, register it to
kernel_map for fault handling.  it probably allows us to remove VACACHE
stuff, too.  kmem_alloc will be backed by a vmem arena which is backed by
kernel_va_arena.

(well, optimizations like direct-mapping etc would be useful, but they
don't change the big picture.)

(while the current implementation of vmem depends on malloc(), it can be
fixed.  vmem branch has the bootstrap code.  it's a little outdated, tho.)

YAMAMOTO Takashi