[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
-----BEGIN PGP SIGNED MESSAGE-----
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
>> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
Main Index |
Thread Index |