On Tue, Jan 08, 2002 at 10:05:42PM +0100, Jaromir Dolecek wrote:
> Chuck Silvers wrote:
> > 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.
> 
> Yes, it could be done using the pools, but it feels a bit icky to me.

hmm, I'm surprised that you like malloc(9) then, since it does pretty
much the same thing I described, except the part that's equivalent to
the pool code has metadata that's safe to access from interrupts.


> It doesn't seem to be possible to stick this into current
> malloc(9) and I don't think it's very reasonable to add completely
> new nointr subpage allocator.

the alternative is to add a "size" argument to free(9) so that there
can be an M_NOINTR flag to specify non-interrupt-safe allocation
(or maybe M_INTR, since that's probably the less common case).


> Given these practical considerations,
> it seems best to just use malloc() (and thus kmem_map) for <PAGE_SIZE
> size, and uvm_km_alloc() for >= PAGE_SIZE.

I very much disagree.  using up the interrupt-safe part of the kernel's
virtual address space for allocations that don't need to be interrupt-safe
just a bad design, certainly much worse than the proposals I've made on
how to avoid it.


> I'm appending patch which does just this. It also adds change to kill
> the program if memory allocation for file descriptor array fails.

this would kill processes unnecessarily, since I've described a way to
avoid having this operation ever fail in practice.  

-Chuck