hi,

in the part of my previous mail after the part you quoted below,
I explained how you can avoid using kmem_map space even for allocations
smaller than a page.  if you use that mechanism for allocating
file descriptor structures, then there would not be any way to
have problems with malloc() failing in this path.  we should use
that same mechanism for all memory allocations where we currently
use malloc() to handle a variably-sized allocation but we don't need
the interrupt-safe property.

-Chuck


On Mon, Dec 17, 2001 at 11:46:00AM +0100, Jaromir Dolecek wrote:
> 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