tech-kern archive

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

Re: vmem problems [was: Re: extent-patch and overview of what is supposed to follow]

On Sat, Apr 09, 2011 at 04:09:40AM +0100, Mindaugas Rasiukevicius wrote:
> Lars Heidieker <> 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
> > 
> > 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


David Young             OJC Technologies      Urbana, IL * (217) 344-0444 x24

Home | Main Index | Thread Index | Old Index