Re: extent-patch and overview of what is supposed to follow

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Hello Lars,

Lars Heidieker <lars%heidieker.de@localhost> wrote:
> this is a part of the changes to the kernel memory management.
> It's a changing the subr_extent to use kmem(9) instead of malloc(9)
> essentially removing the MALLOC_TYPE from it.

Why start from this end, instead of converting extent(9) uses to vmem(9)
and then just retire extent(9) subsystem?

> The next steps will provide the changes to the kmem(9)/pool(9) and the
> pool/uvm_km interface.
> The uvm_km will gain caches for multiplies of the page-size based on
> pool extending the current 1-page-sized cache.
> 
> Making a patch for the pool(9) uvm_km interface changes will be next
> followed by the kmem(9)/malloc(9) merger.
> After that some changes that remove malloc(9) use from sys/uvm/* and
> large parts of sys/kern/* will follow.

I think it would be better to convert malloc(9) to kmem(9) where possible
before the merger.  So we could better see what is left i.e. what memory
allocations are performed from interrupt context.

There is one strong concern.  Merging means converting kmem(9) to use
interrupt-safe map, therefore raised IPL and more blocking of interrupts.
That is not desirable, as interrupt handlers should generally avoid memory
allocation - it seems we all agree that variable-sized allocations there
indicate a flaw, and for constant-sized allocations pool_cache(9) or some
pre-allocation mechanisms should be used.

Hence, as we try to do less work in the interrupt handlers, change to main
memory allocator, resulting in higher "SPL-ing", seems counter-productive.

I would like to see more thoughts from more engineers, particularly yamt@.

-- 
Mindaugas