hi,

not using kernel_object for kernel memory that will never be pageable
is a fine idea.  but could we think about reducing the number of interfaces
and use more flags to get all the variations?

in addition to the other flags you list below, we could add another one
UVM_KMF_PAGEABLE (or something, that's not a great name) to indicate that
the memory might be made pageable at some point in the future with
uvm_map_pageable().  or maybe make it pageable to start with, and let
the caller make it non-pageable in a separate step.

I don't think uvm_km_free() would actually need to be told which flags were
passed to uvm_km_kmemalloc(), it can probably figure everything out from
the contents of the map.

it would probably be best to use uvm_km_alloc() for the name of the unified
interface, now that I think about it.

-Chuck


On Sun, Jan 16, 2005 at 04:04:46PM +0900, YAMAMOTO Takashi wrote:
> hi,
> 
> > is there any reason to use uvm object and managed mappings for
> > wired portions of kernel, like buffer cache and nointr pool backend?
> > if no reason, i'd like to change it because:
> > 	- it wastes resources like pv_entry.
> > 	- it confuses uvm page type balancing. (PR/27030)
> 
> 	- and it complicates bootstrap.
> 
> i'll change uvm_km_* functions like the following, if no one objects.
> 
> - uvm_km_kmemalloc/uvm_km_kmemfree
> 	allocate/free wired kernel memory.
> 
> - uvm_km_valloc/uvm_km_vfree
> 	allocate/free pagable memory backed by kernel_object.
> 
> - uvm_km_kvaalloc/uvm_km_kvafree
> 	allocate/free a kva range.
> 
> - introduce new flags, UVM_KMF_WAITVA, UVM_KMF_ZERO.
> 
> - remove uvm_km_alloc, uvm_km_zalloc, uvm_km_free, uvm_km_valloc_*.
> 
> YAMAMOTO Takashi