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

[Lars Heidieker <lars%heidieker.de@localhost>]

On 04/02/11 02:31, Mindaugas Rasiukevicius wrote:
> 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?
>
There are problems with vmem in the general case as David Young pointed
out http://mail-index.netbsd.org/tech-kern/2009/12/03/msg006566.html

Therefore my idea is to have a resource allocator that combines the
properties of both nothing I have started with except of thinking about it.
eg vmem is returning null in the error case which results in problem
when the resource range should include 0 and making offset wrappers...

Anyway the question of the resource allocator extent/vmem seems to be
orthogonal to the memory allocator question.
 
>> 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@.
>

Indeed the kmem implementation I'm working on uses the kmem_map instead
of kernel_map with the idea to change this after the memory allocation
from interrupt context have been eliminated or moved to their 'prvate'
pools.
I'm fine with identifying those allocations and change them beforehand.

-- 
------------------------------------

Mystische Erklärungen:
Die mystischen Erklärungen gelten für tief;
die Wahrheit ist, dass sie noch nicht einmal oberflächlich sind.

   -- Friedrich Nietzsche
   [ Die Fröhliche Wissenschaft Buch 3, 126 ]