On Sat, Apr 09, 2011 at 04:09:40AM +0100, Mindaugas Rasiukevicius wrote: > Lars Heidieker <[email protected]> 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... > > Just to come back on this.. > > Third problem i.e. vmem(9) relying on malloc(9) is something what needs > fixing, yes. VMEM_ADDR_NULL being 0 does not look like a major problem, > a simple offsetting would work around it, but perhaps (vmem_addr_t *)-1 > would help as well (if its users do not need the whole range, but need > a start at 0).
When I tried to find a simple offset that solved the problem, it looked like the offset needed to be a whole multiple of every potential allocation alignment/boundary (taking a wild guess, that is at least 16M), and that an offset would waste/lose the "top" of a maximum-sized vmem arena, [~(vmem_addr_t)0 + 1 - offset, ~(vmem_addr_t)0]. > And this gets related to problem 2 about ~(vmem_addr_t)0 > being the maximum value in the range - is there a need for a wider space? The problem of ~(vmem_addr_t)0 being excluded should not be difficult to fix. Dave -- David Young OJC Technologies [email protected] Urbana, IL * (217) 344-0444 x24
