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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>