Re: kmem-pool-uvm

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/09/11 02:01, Mindaugas Rasiukevicius wrote:
> yamt%mwd.biglobe.ne.jp@localhost (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
vmem_arena.
- 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.

Lars
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk30j+4ACgkQcxuYqjT7GRZXIgCdHpk9oc0Bm8nYBYxmMWhyhrGZ
WMUAmwbGnre42AWDuMGiE0dc0Efmq1eE
=MhnY
-----END PGP SIGNATURE-----