[PATCH] mm: modify the method to search addr in unmapped_area

[PATCH] mm: modify the method to search addr in unmapped_area

[lipeifeng]

From: lipeifeng <lipeifeng@oppo.com>

The old method will firstly find the space in len(info->length
+ info->align_mask), and get address at the desired alignment.

Sometime, addr  would be failed if there are enough
addr space in kernel by above method, e.g., you can't get a
addr sized in 1Mbytes, align_mask 1Mbytes successfully although
there are still (2M-1)bytes space in kernel.

This patch would fix thr problem above by the new method: find the
space in info->length and judge if at the desired info->align_mask
at the same time.

Do a simple test in TIF_32BIT with unmapped_area:
- Try to take addr (size:1M align:2M) until allocation fails;
- Try to take addr (size:1M align:1M) and account how to space can
be alloced successfully.

Before optimization: alloced 0     bytes.
After  optimization: alloced 1.9+G bytes.

Signed-off-by: lipeifeng <lipeifeng@oppo.com>
---
 mm/mmap.c | 17 ++++++++++++-----
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/mm/mmap.c b/mm/mmap.c
index a28ea5c..cb002f2 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1923,6 +1923,7 @@ static unsigned long unmapped_area(struct vm_unmapped_area_info *info)
 		return -ENOMEM;
 	low_limit = info->low_limit + length;
 
+	length = info->length;
 	/* Check if rbtree root looks promising */
 	if (RB_EMPTY_ROOT(&mm->mm_rb))
 		goto check_highest;
@@ -1944,6 +1945,8 @@ static unsigned long unmapped_area(struct vm_unmapped_area_info *info)
 		}
 
 		gap_start = vma->vm_prev ? vm_end_gap(vma->vm_prev) : 0;
+		/* Adjust gap address to the desired alignment */
+		gap_start += (info->align_offset - gap_start) & info->align_mask;
 check_current:
 		/* Check if current node has a suitable gap */
 		if (gap_start > high_limit)
@@ -1984,15 +1987,19 @@ static unsigned long unmapped_area(struct vm_unmapped_area_info *info)
 	gap_end = ULONG_MAX;  /* Only for VM_BUG_ON below */
 	if (gap_start > high_limit)
 		return -ENOMEM;
-
+	if (gap_start >= info->low_limit) {
+		gap_start += (info->align_offset - gap_start) & info->align_mask;
+		goto return_gap_start;
+	}
 found:
 	/* We found a suitable gap. Clip it with the original low_limit. */
-	if (gap_start < info->low_limit)
+	if (gap_start < info->low_limit) {
 		gap_start = info->low_limit;
+		/* Adjust gap address to the desired alignment */
+		gap_start += (info->align_offset - gap_start) & info->align_mask;
+	}
 
-	/* Adjust gap address to the desired alignment */
-	gap_start += (info->align_offset - gap_start) & info->align_mask;
-
+return_gap_start:
 	VM_BUG_ON(gap_start + info->length > info->high_limit);
 	VM_BUG_ON(gap_start + info->length > gap_end);
 	return gap_start;
-- 
2.7.4

Re: [PATCH] mm: modify the method to search addr in unmapped_area

[Andrew Morton]

On Wed, 20 Apr 2022 16:40:39 +0800 lipeifeng@oppo.com wrote:

> The old method will firstly find the space in len(info->length
> + info->align_mask), and get address at the desired alignment.
> 
> Sometime, addr  would be failed if there are enough
> addr space in kernel by above method, e.g., you can't get a
> addr sized in 1Mbytes, align_mask 1Mbytes successfully although
> there are still (2M-1)bytes space in kernel.
> 
> This patch would fix thr problem above by the new method: find the
> space in info->length and judge if at the desired info->align_mask
> at the same time.
> 
> Do a simple test in TIF_32BIT with unmapped_area:
> - Try to take addr (size:1M align:2M) until allocation fails;
> - Try to take addr (size:1M align:1M) and account how to space can
> be alloced successfully.
> 
> Before optimization: alloced 0     bytes.
> After  optimization: alloced 1.9+G bytes.

Thanks.

Unfortunately this part of the code is undergoing a lot of change
lately.  How serious is this problem?  Please tell us how often the
problem is being observed, under what circumstances, etc.

Re: Re: [PATCH] mm: modify the method to search addr in unmapped_area

[lipeifeng]

>> Unfortunately this part of the code is undergoing a lot of change
>> lately.  How serious is this problem?  Please tell us how often the
>> problem is being observed, under what circumstances, etc.

> I have observed some problems in process-TIF_32BIT, such as Wechat
> and others Android APP.

> In the above processes which the single largest remaining free-addr-space
> is 12Mbytes in some case, we found that the processes wound fail to alloc
> a 12Mbytes(align 1M) in the old methods so that Out-of-Memory.

> The idea of this patch is the same as the following patch which is used for
> unmapped_area_topdown, as follows:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/mm/mmap.c?id=5c6c46912cc0182fadd4b5f0eab029ccbbcc1ba3 

> Thank you very much indeed to ask such nice question and I wish I have given
> a clear reply. Pls let me know If there are any problems you found.

Hi Andrew Morton：

Pls help to review the patch and can it be merged into next-line?
Thanks very much.

lipeifeng@oppo.com
 
From: lipeifeng@oppo.com
Date: 2022-04-21 10:20
To: akpm
CC: peifeng55; linux-mm; linux-kernel; Barry Song; zhangshiming
Subject: Re: Re: [PATCH] mm: modify the method to search addr in unmapped_area
Hi Andrew Morton：

> Unfortunately this part of the code is undergoing a lot of change
> lately.  How serious is this problem?  Please tell us how often the
> problem is being observed, under what circumstances, etc.

I have observed some problems in process-TIF_32BIT, such as Wechat
and others Android APP.

In the above processes which the single largest remaining free-addr-space
is 12Mbytes in some case, we found that the processes wound fail to alloc
a 12Mbytes(align 1M) in the old methods so that Out-of-Memory.

The idea of this patch is the same as the following patch which is used for
unmapped_area_topdown, as follows:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/mm/mmap.c?id=5c6c46912cc0182fadd4b5f0eab029ccbbcc1ba3 

Thank you very much indeed to ask such nice question and I wish I have given
a clear reply. Pls let me know If there are any problems you found.

lipeifeng@oppo.com
 
From: Andrew Morton
Date: 2022-04-21 05:57
To: lipeifeng
CC: peifeng55; linux-mm; linux-kernel; 21cnbao; zhangshiming
Subject: Re: [PATCH] mm: modify the method to search addr in unmapped_area
On Wed, 20 Apr 2022 16:40:39 +0800 lipeifeng@oppo.com wrote:
 
> The old method will firstly find the space in len(info->length
> + info->align_mask), and get address at the desired alignment.
>
> Sometime, addr  would be failed if there are enough
> addr space in kernel by above method, e.g., you can't get a
> addr sized in 1Mbytes, align_mask 1Mbytes successfully although
> there are still (2M-1)bytes space in kernel.
>
> This patch would fix thr problem above by the new method: find the
> space in info->length and judge if at the desired info->align_mask
> at the same time.
>
> Do a simple test in TIF_32BIT with unmapped_area:
> - Try to take addr (size:1M align:2M) until allocation fails;
> - Try to take addr (size:1M align:1M) and account how to space can
> be alloced successfully.
>
> Before optimization: alloced 0     bytes.
> After  optimization: alloced 1.9+G bytes.
 
Thanks.
 
Unfortunately this part of the code is undergoing a lot of change
lately.  How serious is this problem?  Please tell us how often the
problem is being observed, under what circumstances, etc.