Chuck Silvers wrote:
> however, file-descriptor tables don't need to be accessed from interrupt
> context, so there's no need for them to be allocated from kmem_map, except
> that malloc() can only allocate from kmem_map.  so what we'd really like
> is a way to allocate variably-sized chunks of memory from kernel_map instead
> of kmem_map.  we can do that with uvm_km_alloc() for chunks that are a
> multiple of the page size, so another approach would be to have fdexpand()
> switch to using uvm_km_alloc() instead of malloc() once the size of the
> allocation becomes larger than a page.  this would greatly reduce the
> usage of kmem_map space for this application which really doesn't need it.

Yes, I think that using uvm_km_alloc() there would be good if size
of the array would be > PAGE_SIZE. We can even use uvm_km_valloc_wait(),
since we should be safe to get page faults in that context, and that
would provide us with the 'sleep if memory scarce' semantics I
though malloc(9) has. Plus, it would allocate extra physical memory
lazily, which is what we want in common case.

Even if we used uvm_km_*() for >PAGE_SIZE, M_CANFAIL is still
useful.  Even the <PAGE_SIZE malloc(9) could fail due to kmem_map
shortage, and it's not appropriate to panic in that case IMHO.

So, it seems this would be good solution:
1. use uvm_km_valloc_wait() once the array size is >= PAGE_SIZE
2. use malloc(M_CANFAIL) for array size < PAGE_SIZE
3. if either of those fails, exit1() the process, as if SIGKILLed
   (and log reason)

Jaromir
-- 
Jaromir Dolecek <jaromir.dolecek@artisys.cz>
ARTISYS, s.r.o., Stursova 71, 61600 Brno, Czech Republic
phone: +420-5-41224836 / fax: +420-5-41224870 / http://www.artisys.cz