mm/mmap.c: fix the adjusted length error

mm/mmap.c: fix the adjusted length error

[Matthew Wilcox]

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@huawei.com

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.

Re: mm/mmap.c: fix the adjusted length error

[Andrew Morton]

On Mon, 8 Mar 2021 18:50:02 +0000 Matthew Wilcox <willy@infradead.org> wrote:

> 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@huawei.com
> 
> 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.

OK, thanks.  The patch is very old, and stuck.  I'll drop it.