-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/09/11 02:01, Mindaugas Rasiukevicius wrote: > y...@mwd.biglobe.ne.jp (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-----
