tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kmem-pool-uvm

Hash: SHA1

On 06/09/11 02:01, Mindaugas Rasiukevicius wrote:
> (YAMAMOTO Takashi) wrote:
>>>> let me explain some background. currently there are a number of
>>>> kernel_map related problems:
>>>> A-1. vm_map_entry is unnecessarily large for KVA allocation purpose.
>>>> A-2. kernel-map-entry-merging is there to solve A-1. but it introduced
>>>> the allocate-for-free problem. ie. to free memory, you might need to
>>>> split map-entries thus allocate some memory.
>>>> A-3. to solve A-2, there is map-entry-reservation mechanism. it's
>>> complicated and broken.
>> <...>
>> i agree that having two allocator for KVA is bad.
>> my idea is having just one. (kernel_va_arena)
>> no allocation would be made by vm_map_entries for kernel_map.
>> kernel_map is kept merely for fault handling.
>> essentially kva allocation would be:
>>      va = vmem_alloc(kernel_va_arena, ...);
>>      if (pageable)
>>              create kernel_map entry for the va
>>      else
>>              ...
>>      return va;
> I like this a lot.  Seems an overall win.

Yes, definitly it simplifies locking a lot. But I don't like the idea of
mixing vmem and map entries. I think it's cleaner to have one
vm_map_entry spawning the entire heap which in turn is controlled by a
- From there on two options emerge:
Making kmem(9) interrupt safe, which seems to have some runtime overhead
or to retrofit malloc(9) (for the time it is still there) into the vmem
backed world.

Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


Home | Main Index | Thread Index | Old Index