Re: [PATCH -mm v2 01/11] mm: track free size between VMAs in VMArbtree

[Rik van Riel]

On 06/22/2012 10:37 AM, Peter Zijlstra wrote:
> On Fri, 2012-06-22 at 10:25 -0400, Rik van Riel wrote:
> > On 06/22/2012 10:13 AM, Peter Zijlstra wrote:
> > > On Fri, 2012-06-22 at 10:11 -0400, Rik van Riel wrote:
> > > > I am still trying to wrap my brain around your alternative
> > > > search algorithm, not sure if/how it can be combined with
> > > > arbitrary address limits and alignment...
> > >
> > > for alignment we can do: len += align - 1;
> >
> > We could, but that might lead us to returning -ENOMEM
> > when we actually have memory available.
> >
> > When you consider architectures like HPPA, which use
> > a pretty large alignment, but align everything the same,
> > chances are pretty much every freed hole will have the
> > right alignment...
>
> Well, if you don't your gap heap is next to useless and you'll revert to
> simply walking all gaps until you find a suitable one.

I could see how that might potentially be a problem,
especially when we have a small allocation with large
alignment constraints, eg. HPPA cache alignment.

> I really worry about this search function of yours, its complexity is
> very non obvious.

Let me try implementing your algorithm with arbitrary
address constraints and alignment/colouring.

Basically, we need to remember if the allocation failed
due to bad alignment.  If it did, we add shm_align_mask
to the allocation length, and try a second search.

This should result in at worst two whole tree traversals
and one partial traversal. Less on sane architectures,
or for non-MAP_SHARED allocations.

--
All rights reversed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/