Hi Andrew, You have a patch in your tree which I think is a bad idea. Link: http://lkml.kernel.org/r/1558073209-79549-1-git-send-email-chenjianhong2@xxxxxxxxxx The problem it describes is real -- if you chew up all the address space with 64MB pages, free one and then try to allocate another one, it will fail. I don't like the solution, though. If memory is fragmented in a different way from that described by the patch, it will cause us to walk into rbtree nodes that look like they might be able to satisfy our allocation, only to find that they cannot, due to alignment issues. In the worst case, it turns into a linear scan of the address space instead of logarithmic. I would prefer to see this solved by doing two passes. The first would look for a 128MB size hole, as we do now, which is guaranteed to find us a 64MB hole if it succeeds. If that search fails, then we can fall back to the 64MB hole search, as done in this patch.
